On 10/10/2011 03:30 PM, tom fogal wrote:
One of our programs which relies on shaders heavily is having issues,
and I have tracked it down to unexpected values in gl_NormalMatrix
within the fragment shader.

Using the attached program (patch against mesademos repo) I did
printf-esque debugging to get the values of gl_NormalMatrix.  Search
for 'fragShaderText' to see the shaders I'm using.  I get different
results on a Mesa 7.10.2 (Ubuntu 11.04) system with an Intel card
versus an nvidia-binary-blob system.  The nvidia-based system also
agrees with what I get using any card on a Mac and nvidia or ATI
cards on Windows (native drivers, not Mesa); we have no results for
Windows/Intel yet.

       nvidia                  intel
[ 1.0   0.0   0.0 ]    [ 1.0   0.0   0.0  ]
[ 0.0  -0.0   1.0 ]    [ 0.0   0.0>0.0,<0.0001 ]
[ 0.0  -1.0  -0.0 ]    [ 1.0  15.0   0.0  ]

I used "-0.0" for a couple slots on the nvidia system; the value was
smaller than 0.0, but larger than 0-epsilon for some small epsilon,
similar to gl_NormalMatrix[1].z on intel but in the opposite direction.

I spot-checked gl_NormalMatrix[2].y with LIBGL_ALWAYS_SOFTWARE=1.  In
that case, Mesa agrees with the nvidia driver: the value is -1.0.  My
application also produces imagery identical (via a subjective eye test,
haven't tried image differencing the two) to the nvidia system when I
run it with LIBGL_ALWAYS_SOFTWARE=1.

I think I see what the test is trying to produce. Basically, it's checking columns of the matrix to see if they match expected values. If a particular column doesn't match, a certain color is output.

I think we could make a more general piglit test the reproduce this sort of failure. Something like:

uniform mat4 expected;

void main()
{
    /* Check a different column of the gl_NormalMatrix depending
     * which quadrant of the screen we're in.
     */
    if (gl_FragCoord.x < 0.0) {
        if (gl_FragCoord.y < 0.0) {
            a = expected[0];
            b = gl_NormalMatrix[0];
        } else {
            a = expected[1];
            b = gl_NormalMatrix[1];
        }
    } else {
        if (gl_FragCoord.y < 0.0) {
            a = expected[2];
            b = gl_NormalMatrix[2];
        } else {
            a = expected[3];
            b = gl_NormalMatrix[3];
        }
    }

    float d = distance(a, b);
    gl_FragColor = (d < 0.00001)
        ? vec4(0.0, 1.0, 0.0, 1.0)
        : vec4(1.0, 0.0, d,   1.0);
}

On the intel system:

   GL_VENDOR: Tungsten Graphics, Inc
   GL_RENDERER: Mesa DRI Intel(R) Sandybridge Desktop GEM 20100330 DEVELOPMENT
   GL_VERSION: 2.1 Mesa 7.10.2

 From 'dmesg', I gather the GPU is an i915.

Sandybridge is the most recently released GPU in the i965 family. It shares the i915 kernel driver with several earlier GPUs.

Is this a known issue?  Any workarounds available?  Anything else I
could do to help debug?

Yikes! A *lot* has changed in the fragment shader back-end for i965 since 7.10.2. Have you at least tried 7.10.3? 7.11?

Also, the changes to the Makefile don't seem to be sufficient to make it build for me. I had to just build it by hand.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to