GNOME Bugzilla – Bug 677078
GLSL detection not working for Intel GMA3150 chipset
Last modified: 2012-06-20 11:58:04 UTC
The GLSL detection in cogl is done by testing for the presence of glCreateProgram; however, the function pointer is forced to NULL unless GL version is at least 2.0 (I gather this is because in Mesa this function is always present, but not necessarily working). With the GMA3150 chipset the Intel driver from mesa 8.0.3 (also 7.11) supports GLSL 1.20 but only reports GL version 1.4 -- AFAICT the sole reason for this is that the driver does not implement GL_ARB_occlusion_query, which is necessary for GL 1.5 and above. Rather than relying on the overall GL version when clobbering the glCreateProgram pointer, would it not be better to test the output from glGetString(GL_SHADING_LANGUAGE_VERSION)?
Neil, Rob: I will bring a breaded good of your choice to the office when this is resolved. :)
I'm guessing that GMA3150 will support the GL_ARB_shader_objects extension and friends if it can do GLSL. It would probably be better to check for that rather than trying to use API that isn't advertised. The reason we haven't done it before is that the extension is slightly different from the API provided in GL 2.0 so it's a bit of faff. I'm about to attach a patch against the cogl-1.10 branch to make it do this. It would be great if you could try it.
Created attachment 215238 [details] [review] Use the old GLSL extensions if GL 2.0 is not available Some drivers have good support for GLSL but don't have the complete set of features needed to advertise GL 2.0 support. We should accept the three old GLSL extensions (GL_ARB_shader_objects, GL_ARB_vertex_shader and GL_ARB_fragment_shader) to support shaders on these drivers. This patch splits the shader functions into four sections :- those that are provided only in GL 2.0, those that have the same name in the shader objects extension, those that are provided by the vertex shader extension (they all share the same name) and those that have a different name in the shader objects extension. If GL 2.0 is not supported but all three of the extensions are then the pointers to the GL2-only functions will be replaced to point to the equivalent functions from the extensions. That way the rest of the Cogl source doesn't have to worry about the name differences.
(In reply to comment #2) > I'm guessing that GMA3150 will support the GL_ARB_shader_objects extension and > friends if it can do GLSL. It would probably be better to check for that rather > than trying to use API that isn't advertised. But the GLSL API is advertised, you are just not checking for it in cogl; see http://www.opengl.org/wiki/Detecting_the_Shader_Model. (In the 3150 case the driver advertises GLSL 1.20, which is what you would be getting with GL 2.1).
I think that table is saying that "if you have GL version X then you have at least GLSL version Y" but it does not mean that having GLSL version Y implies GL version X. The old GLSL extensions also provide the glGetString(GL_SHADING_LANGUAGE_VERSION) query so it seems perfectly legitimate to make a driver that only supports the old API for creating shaders but supports a modern GLSL language version. The old API behaves more or less identically to the API provided by GL 2.0 but with different names so I don't think there's any advantage to assuming we can use the GL 2.0 functions. Using only functions that are actually advertised should make it more robust against picky drivers.
Review of attachment 215238 [details] [review]: I can confirm that the order for the breaded good can be placed!
Comment on attachment 215238 [details] [review] Use the old GLSL extensions if GL 2.0 is not available This looks good to land to me. Sorry for the delay in reviewing this.
Ok, I've pushed it to master and the cogl-1.10 branch. Thanks.