System Environment: -------------------------- Platform: Sandybridge Libdrm: (master)libdrm-2.4.54-17-ge8c3c1358ecaf4e90f7d43762357ae6f8e2022b6 Mesa: (master)50bbe49c330095ba451d0f48c56759d148a609c2 Xserver: (master)xorg-server-1.15.99.902-121-g2f5cf9ff9a0f713b7e038636484c77f113a5f10a Xf86_video_intel:(master)2.99.912-227-g8587b2fff218537c6ff568ac3ef561f0d39f03ff Libva: (master)c61d8c6ce9ffc27320e9e177c1e1123d5f1b5014 Libva_intel_driver:(master)c5cb17ea86f0065a939d3636dd26651c93d497c8 Kernel: drm-intel-nightly/ed4d04defe2c6962efe8f4ba3587a8e69e06d2dd Bug detailed description: ------------------------- It fails on Sandybridge(i386) with mesa master and 10.2 branch. It works well on x86_64 machine. It was pass in earlier our nightly testing, fails now. But I can't reproduce the pass. Following cases also fail: spec_arb_shading_language_packing_execution_built-in-functions_fs-unpackSnorm4x8 spec_arb_shading_language_packing_execution_built-in-functions_fs-unpackUnorm4x8 spec_arb_shading_language_packing_execution_built-in-functions_vs-packSnorm4x8 spec_arb_shading_language_packing_execution_built-in-functions_vs-unpackSnorm4x8 spec_arb_shading_language_packing_execution_built-in-functions_vs-unpackUnorm4x8 output: Probe color at (0,0) Expected: 0.000000 1.000000 0.000000 1.000000 Observed: 1.000000 0.000000 0.000000 1.000000 PIGLIT: {'result': 'fail' } Reproduce steps: ------------------------- 1. bin/shader_runner generated_tests/spec/arb_shading_language_packing/execution/built-in-functions/fs-packSnorm4x8.shader_test -auto
I can replicate this with a 32-bit build of Mesa on Sandybridge. However it also needs to be built with -O3. If I build with -O0 then the test passes. The fragment shader generated in both builds is identical.
Created attachment 104307 [details] Simpler test case This bug is pretty strange. It seems to be related to uploading unsigned int uniforms. One of the tests tries to upload the value 2139193217 (which is 0x7f817f81). For some inexplicable reason this appears to end up in the shader as 0x7fc17f81, but only if you build with -O3. I'm attaching a simpler test case which demonstrates it. It has a fragment shader with an unsigned int uniform and renders the four bytes of the uniform to a floating-point texture. It then prints out the values. You can specify an alternative test value as a command line argument. It seems to be something very specific about having 0x7f in the most-significant 8 bits. 0x80, 0x6f or 0x8f work fine. I am replicating this on a 32-bit build on SandyBridge. It doesn't happen on a 64-bit build with Haswell, but I'm not sure whether it's the SandyBridge or the 32-bit that's important.
Glenn Kennard on IRC pointed out that setting bit 22 like that resembles a NaN value getting munged when loading and storing through a floating-point register. Indeed if I write a quick test that does fld and fst with 0x7f817f81 it comes out as 0x7fc17f81. I guess this works on 64-bit because that will use SSE which apparently doesn't try to fix up NaNs on store. It also gets fixed on the 32-bit SandyBridge build if I use -mfpmath=sse and -msse2.
I've posted a patch here: http://lists.freedesktop.org/archives/mesa-dev/2014-August/065179.html I also tested on a 32-bit build on Haswell and the same bug is there. The patch also fixes it there because the same gen6 function is used.
(In reply to comment #4) > I've posted a patch here: > > http://lists.freedesktop.org/archives/mesa-dev/2014-August/065179.html > > I also tested on a 32-bit build on Haswell and the same bug is there. The > patch also fixes it there because the same gen6 function is used. Fixed by this patch.
I've pushed a different patch which should hopefully fix the bug: http://cgit.freedesktop.org/mesa/mesa/commit/?id=2c50212b14da27de4e3da62488ae4e3
Verified.Fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.