[Mesa-dev] Shading language extension

Ian Romanick idr at freedesktop.org
Thu Oct 21 18:09:51 PDT 2010

Hash: SHA1

Ian Romanick wrote:
> There are a number of shading language extension currently in Mesa or
> soon to be in Mesa that don't have any driver dependent parts.  Would
> anyone object to having these extensions be enabled automatically when
> GLSL is enabled?
> The list that I'm think of is:
>  - GL_ARB_explicit_attrib_location (now)
>  - GL_EXT_separate_shader_objects (very soon)
>  - GL_AMD_conservative_depth (soon)
>  - GL_ARB_shading_language_include (eventually)
> There are a couple other extensions in progress that will probably be
> added to this list once they are released.

I got to looking at this, and I have a slightly different idea.  How
about it we always enable:

 - GL_ARB_shader_objects
 - GL_ARB_shading_language_100
 - GL_ARB_explicit_attrib_location
 - GL_EXT_separate_shader_objects (very soon)
 - GL_ARB_shading_language_include (eventually)

We can then always enable GL_AMD_conservative_depth when
GL_ARB_fragment_shader is enabled.

Is there a compelling to not force-enable those extension?  I don't
think it will break any applications.  Applications typically either
check for OpenGL 2.0 or GL_ARB_vertex_shader / GL_ARB_fragment_shader.

The core profile of later versions of OpenGL remove support for older
versions of the shading language.  Because of that, I don't want to have
later extensions, like GL_ARB_explicit_attrib_location, tied to
GL_ARB_shading_language_100.  The real answer here might just be that
our extension management needs a major revamp.  The mess of exporting ES
extensions provides some evidence.

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the mesa-dev mailing list