Re: [Dri-devel] OpenGL 1.3, 1.4, and extension string issue

[Ian R. <id...@us...>]

On Thu, Oct 17, 2002 at 04:39:19PM +0100, Keith Whitwell wrote:
> Ian Romanick wrote:
> 
> >>From what I have been told, this is how it works on the Nvidia drivers.  I
> > have not verified this first hand.
> > 
> >     if ( extension string contains "GL_EXT_texture3D" )
> >         3D textures are hardware accelerated
> >     else if ( advertised OpenGL version >= 1.2 )
> >         3D textures are a software fallback
> >     else
> >         3D textures are not supported at all
> > 
> > So, a TNT will advertise OpenGL version 1.2 but not GL_EXT_texture3D.  3D
> > textures will work, but they will be sw rendered.  On whichever Geforce
> > supports 3D textures in hw, OpenGL version 1.2 AND GL_EXT_texture3D would be
> > advertised.  It's not a perfect system, but it fixes most of the cases where
> > an app checks the extension string to see of some feature is supported in
> > hardware and gets an upleasant surprise from a sw fallback.
> 
> It does seem semantically richer than the standard way of doing things.  I 
> wonder if the spec gives some wiggle room on this.

That's actually how all this got started.  I noticed that Mesa / DRI doesn't
advertise extension strings for a LOT of OpenGL 1.2 functionality that IS
supported:

	- EXT_draw_range_elements
	- EXT_separate_specular_color
	- EXT_texture_edge_clamp / SGIS_texture_edge_clamp
	- SGIS_texture_border_clamp
	- SGIS_texture_lod

So, I asked a couple people around IBM what the accepted practice was.  I
was told that an implementation is not required to export extension strings
for extensions that are required for its adverteised OpenGL version.  I was
then told about Nvidia's technique.

-- 
Smile!  http://antwrp.gsfc.nasa.gov/apod/ap990315.html