Bug 81150 - [SNB]Piglit spec_arb_shading_language_packing_execution_built-in-functions_fs-packSnorm4x8 fails
Summary: [SNB]Piglit spec_arb_shading_language_packing_execution_built-in-functions_fs...
Status: VERIFIED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Neil Roberts
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-10 07:22 UTC by lu hua
Modified: 2014-08-18 02:29 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Simpler test case (7.67 KB, text/plain)
2014-08-08 18:24 UTC, Neil Roberts
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lu hua 2014-07-10 07:22:48 UTC
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
Comment 1 Neil Roberts 2014-08-08 15:21:27 UTC
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.
Comment 2 Neil Roberts 2014-08-08 18:24:34 UTC
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.
Comment 3 Neil Roberts 2014-08-08 19:05:59 UTC
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.
Comment 4 Neil Roberts 2014-08-08 20:57:57 UTC
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.
Comment 5 lu hua 2014-08-13 06:37:40 UTC
(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.
Comment 6 Neil Roberts 2014-08-14 11:08:11 UTC
I've pushed a different patch which should hopefully fix the bug:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=2c50212b14da27de4e3da62488ae4e3
Comment 7 lu hua 2014-08-18 02:29:00 UTC
Verified.Fixed.


bug/show.html.tmpl processed on Jan 18, 2017 at 04:10:07.
(provided by the Example extension).