On Thu, Jan 9, 2014 at 4:04 AM, Ilia Mirkin <imir...@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 _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau