On Tue, 15 Feb 2000, Thomas Roell wrote:
> In your message of 14 February 2000 you write:
>
> > Michael Gold rightly pointed out that, if any formal requirements
> > would be imposed on strings retrieved from GL, an extension would
> > have to be defined. We can't retrofit GL_RENDERER with additional
> > requirements. No matter how we turn it, it has nothing to with
> > ABI specs. Thomas Roell was merely trying to humor my request for
> > a good list of tokens.
>
> Actually yes and no. GL_VENDER and GL_RENDERER should (IMHO) be used
> to just identify a configuration within the vendors own universe.
> However as a vendor myself, there is a lot missing. Besides having all
> those HW related things, there really should be a way for an
> application to figure out, what core-API functions and what extensions
> are done in SW only, vs. which ones can use HW support. Maybe that is
> something to think about.
Cap bits by the back door are still cap bits - and all the usual
arguments apply. What if there are two features and the hardware
can do one *OR* the other in hardware? What if the function is
in software because it's faster than the hardware? What if the
feature is in software with one set of glEnable's and in hardware
with another? What percentage of a function's execution time
has to be in the hardware for you to set the Cap Bit? What if
the software has to block when the hardware is doing this thing?
Yada yada yada.
PLEASE let's not go there. This is OpenGL and it doesn't have
Cap Bits even if they are sneaked in by the back door within
the GL_RENDERER string.
...and in any case, this doesn't belong in ABI. The ABI spec
isn't a mechanism for specifying lots of cool OpenGL extensions
- it's a mechanism for ensuring binary compatibility between
OpenGL's implementing the existing OpenGL spec.
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
