[Mesa-dev] gl_NormalMatrix issue on Intel driver

[tom fogal]

Ian Romanick <idr at freedesktop.org> writes:
> 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.

Yeah, exactly; I was just modifying the 'if' conditional, recompiling,
looking at the color, goto 10 ...

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

The issue I find with shaders and specifically this is that what I
really want to do is:

  if(!within_epsilon(gl_NormalMatrix[0].x, expected)) {
    printf("[0][0] produced %g instead of %g, gl_NormalMatrix[0].x, expected);
  }
  ...

but of course you can't printf anything in a shader.  Your test program
is along the same lines... I guess there must be a way in piglit to say
we expect a color to be a particular value?  Via say glReadPixels?

I haven't pulled piglit in well over a year.  I'll take a look at how
those tests work and try to generate a test program for that repo after
this email.

> > On the intel system:
> >
> >    GL_VENDOR: Tungsten Graphics, Inc
> >    GL_RENDERER: Mesa DRI Intel(R) Sandybridge Desktop GEM 20100330 DEVELOPM
> ENT
> >    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.

Ahh, okay; it was confusing because I /knew/ an i965 existed and
was 'better' than an i915, and we just recently bought this machine
specifically to get our code running on Intel cards.

Thanks for the clarification!

> > 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?

I have not.  To be honest, I am pretty daunted by trying a new X
driver.  I don't quite understand the interaction between drm, the
kernel, X proper, and Mesa to know what needs to be compiled, nor have
I ever found good documentation on how to swap out my driver on either
mesa3d.org or intellinuxgraphics.org.

I am completely comfortable compiling/trying out master, even, if I
knew how... can I just LD_PRELOAD the new libGL, perhaps?

> 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.

The diff only changed CMakeLists.txt; you'd need to re-run cmake for it
to pick up on it.  I didn't actually intend for it to get merged into
mesademos, but if that's desired I can patch the GBS in that tree as
well.

Thanks,

-tom