[Mesa-dev] Shading language extension

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
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.

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

iEYEARECAAYFAkzA5FwACgkQX1gOwKyEAw/iMACgh/6ARb1+zjII4nnrjiagP3Ig
ujIAn2w0gFOGljP52ASdZDIEm8o+gj+b
=ctR8
-----END PGP SIGNATURE-----