The renderer setting r_allowSoftwareGL is implemented using the SDL attribute SDL_GL_ACCELERATED_VISUAL. With more recent ATI drivers, this setting does exactly the opposite of what it's supposed to. The relevant SDL source looks sane enough to me, so it seems reasonable to point the finger at the ATI drivers. I don't have an ATI card myself though, so I can't really offer more information.
The feature in question isn't that important though, so I'm disabling it for now.
Well, the SDL code is a bit strange: is specifies the WGL_ACCELERATION_ARB attribute twice !
First it is set to WGL_FULL_ACCELERATION_ARB, and later when the SDL attribute is set, it is specifies again as either WGL_GENERIC_ACCELERATION_ARB or WGL_NO_ACCELERATION_ARB.
ATI/AMD seems to pick the second value if an attribute is specified twice (the spec is unclear how the driver should handle this case) and so the SDL attribute can choose only between the two slow OpenGL modes...
So you have to skip the SDL_GL_SetAttribute to get the (fast) ICD drivers.
Thank you. I wouldn't depend on the catalyst driver fixing anything, though. The bug was still present in a fairly recent driver that I tested.
Also, quake3 engines seem to have an abysmal performance with the catalyst driver, at least on windows. Strangely, users have reported renaming the exe file to "quake3.exe" fixed these issues for them.
(In reply to comment #5)
> Also, quake3 engines seem to have an abysmal performance with the catalyst
> driver, at least on windows. Strangely, users have reported renaming the exe
> file to "quake3.exe" fixed these issues for them.
You probably already know this, but it's relatively well known that various video drivers detect Q3 and enable a specific optimal code path that performs well with the way Q3 uses the OpenGL API.
I think this is an SDL bug: http://bugzilla.libsdl.org/show_bug.cgi?id=1254 http://bugzilla.libsdl.org/show_bug.cgi?id=1197 I'll be applying patches for this in SDL 1.2 and 1.3 soon (and, some argue it's technically a Catalyst driver bug too, which means it might be fixed there, too). --ryan.