Ian Romanick <i...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
