[Mesa-dev] Shading language extension
idr at freedesktop.org
Thu Oct 21 18:09:51 PDT 2010
-----BEGIN PGP SIGNED MESSAGE-----
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_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/
-----END PGP SIGNATURE-----
More information about the mesa-dev