[Mesa-dev] gl_NormalMatrix issue on Intel driver

[Ian Romanick]

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.