Bug 33925 - GLSL linker bug
Summary: GLSL linker bug
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: 7.7
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2011-02-04 19:33 UTC by Fredrik Tolf
Modified: 2011-02-15 15:41 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Fredrik Tolf 2011-02-04 19:33:43 UTC
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.
Comment 1 Ian Romanick 2011-02-07 13:47:43 UTC
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?
Comment 2 Fredrik Tolf 2011-02-07 14:24:02 UTC
Not sure how much APT breakage that would entail, but I'll try.
Comment 3 Ian Romanick 2011-02-08 10:17:04 UTC
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
Comment 4 Fredrik Tolf 2011-02-14 07:42:33 UTC
> 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).
Comment 5 Ian Romanick 2011-02-15 15:41:49 UTC
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.