I've been playing around a bit with GLSL as of late, and have encountered a situation which is hard for me to ascribe to anything but a linker bug. It seems that varying variables from the vertex and fragment shaders aren't matched correctly. I've been trying to write a module shader architecture that generates a main function to call other shaders in separately compiled shader objects. Just trying to get everything working correctly, I was trying to use the texture coordinates of a model as the output color for the fragments. Currently, I'm compiling and linking the following shaders: -- Vertex shader source: varying vec4 texc; void null() {texc = gl_MultiTexCoord0;} -- Generated vertex shader main function: void null(); varying vec4 b; void main() { vec4 fcol = gl_Color; vec4 bcol = gl_Color; vec4 objv = gl_Vertex; vec3 objn = gl_Normal; null(); vec4 eyev = gl_ModelViewMatrix * objv; vec3 eyen = gl_NormalMatrix * objn; gl_FrontColor = fcol; gl_BackColor = bcol; b = vec4(objn, 0); gl_Position = gl_ProjectionMatrix * eyev; } -- Fragment shader source: varying vec4 texc; void null(inout vec4 res) {res = vec4(texc.xy, 0.0, 1.0);} -- Generated fragment shader main function: void null(inout vec4 res); varying vec4 b; void main() { vec4 res = gl_Color; null(res); gl_FragColor = b; } I started out without the "b" variable, setting gl_FragColor in the main function to the "res" variable instead, but that made all the fragments yellow (as if texc contained only 1.0), so I added the "b" variable for debugging. As you can see in the main vertex shader function, I set it to each vertex's normal. However, in the actual output, I'm seeing the texture coordinates rendered as the fragments' final color (my originally intended result). Is there any way to interpret this other than "b" in the fragment program being linked to "texc" from the vertex program? I've got an Intel Arrandale chipset, which uses the i965 DRI driver, which is why I filed the bug with that, but I guess that choice of component may be completely wrong. I'm running stock Debian Squeeze, which means Mesa version 7.7.1, xserver-xorg-video-intel 2.13.0 and Linux 2.6.32.
The entire GLSL compiler stack, including the linker, has been completely rewritten since 7.7.1. Could you retry with either Mesa 7.9.1 or Mesa 7.10?
Not sure how much APT breakage that would entail, but I'll try.
I'm not sure what you mean by "APT breakage." You should be able to just build it, add <build dir>/lib64 to your LD_LIBRARY_PATH, and set LIBGL_DRIVERS_PATH to <build dir>/lib64. Something like the following (all on one line): LD_LIBRARY_PATH=~/mesa/lib64 LIBGL_DRIVERS_DIR=~/mesa/lib64 glxinfo | grep '^OpenGL [vr]e' should show something like OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile GEM 20100330 DEVELOPMENT OpenGL version string: 2.1 Mesa 7.9.1
> You should be able to just build it, add <build dir>/lib64 to your > LD_LIBRARY_PATH, and set LIBGL_DRIVERS_PATH to <build dir>/lib64. For some reason, that didn't work very well (it made rendering very slow), but I did manage to pull in mesa 7.10 from Debian unstable (it had incomplete dependencies on libdrm, however, which took me some time to figure out), which worked as it should. I can thus confirm that this bug is not present in 7.10 (as expected, I guess). There does seem to be some other bug, however, but if it turns out to really be a bug, I'll file a separate report on it (I haven't investigated thoroughly yet, but it seems that all gl_LightSource elements after the first are just copies of the first).
Okay. I'll close this bug. If you can reproduce the gl_LightSource issue, please submit another bug. We don't have a lot of coverage of built-in uniforms in our test suite, so it won't surprise me if there is a bug there.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.