-----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----- _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev