Michael Vance writes:
> Thomas Roell wrote:
> > It would just be very nice to have some kind of hinting-scheme.
> You still can't do it effectively.
The Quake engines and their offspring contain some code to identify
certain drivers/hardware and enable or disable features. Combined
with Quake's Cvars (which let the user override such autodetection)
it is a possible solution if you want to support a partially broken
but ubiquituous hardware/driver.
In general, the ability to identify hardware vendor and board/
configuration, driver version/date, and other stats is handy.
It is an option to work around a problem when you positively
have to ship a game/app before the drivers are fixed by the
vendor, or if the ubiquituous hardware mentioned above can't
be fixed. That's not a hinting scheme, it is the minimum
requirement to identify a given hardware/driver against a
more or less incomplete database of targets you are prepared
to deal with.
As an example, Linux X11 applications supporting windowed
modes will have to identify 3dfx passthru legacy for quite
some time.
I don't see anything wrong with contemplating e.g. a
GL_ACCELERATOR_ID/GL_DRIVER_ID extension, but as been pointed out,
this is not an ABI issue, and it is a bad idea to retrofit
GL_RENDERER with a couple of underspecified requirements.
b.
