Nouveau - Jan 2014 - commit 0a1479c829 breaks glsl-fs-lots-of-tex.shader_test on nv50/nvc0

On Thu, Jan 9, 2014 at 4:04 AM, Ilia Mirkin <imirkin at alum.mit.edu>
wrote:
> Hi Marek,
>
> I won't pretend to understand what's going on, but I just bisected
a
> failure on tests/shaders/glsl-fs-lots-of-tex.shader_test in piglit
> between 9.1 and HEAD, and it landed on your commit. It's approximately
> the simplest shader known to man (esp at HEAD when all the TEX
> instructions are gone due to CSE), so I'm guessing there's some
edge
> condition in the copying logic triggered by it.
Christoph,

I spoke with Marek earlier on IRC, and he thought it was probably an
issue in our ->blit routine. I agree that this makes sense, however
that's the only piglit test that fails in tests/shaders (well, related
to textures), and there are plenty of other texture2D-using tests. I
looked at the mmt traces, and they seem pretty reasonable. What's
unique about this test is that it uses a 0.01 value in the texture
rather than the more common 1/-1.

FWIW the failure looks like:

$ bin/shader_runner tests/shaders/glsl-fs-lots-of-tex.shader_test -auto
Probe color at (187,187)
  Expected: 0.400000 0.000000 0.000000
  Observed: 0.266667 0.000000 0.000000
PIGLIT: {'result': 'fail' }

So it's getting a value... just not the right one. The blit is being
done from RGBA32_FLOAT to RGBA8_UNORM.

So, doing the math, 0.01 * 255 = 2.55, so the value should be 3 (I
guess "norm" is supposed to round?). 3/255 * 34 = 0.4. And 2 / 255 *
34 = 0.266666. So... it's getting rounded down instead of up. Changing
the value to 0.011 "fixes" the piglit test (since 0.011 * 255 = 2.8,
which is unambiguously closer to 3).

Are you aware of any rounding mode stuff, or is the hw just inaccurate
at rounding? i.e. is there a fix here, or should I try to update the
piglit test to use 0.011 instead of 0.01?

  -ilia