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
