System Environment: -------------------------- Platform: ILK Libdrm: (master)libdrm-2.4.60-17-g8dff7a04780a0f028aa7c0218806a5ee59b1a40d Mesa: (master)7c7954b09dd28502aedb3eed312672620b9e6b7a Xserver: (master)xorg-server-1.17.0-23-g0a78b599b34cc8b5fe6fe82f90e90234e8ab7a56 Xf86_video_intel:(master)2.99.917-203-g44452825fb862c81957f53e04f739e2d96864f91 Libva: (master)dbeeed0ec1b5eb192380fcdacfea86e0de1584af Libva_intel_driver:(master)8ac2289aca552998d290bbc8bc2b44fbb510b1f9 Kernel: (drm-intel-nightly)294a23a2fbb36c57ea89b5cfde94017c6a1124a2 Bug detailed description: ------------------------- It fails on mesa master branch,works well on 10.5 branch. Following cases also fail: ES2-CTS.gtf.GL.equal.equal_vec3_frag ES2-CTS.gtf.GL.notEqual.notEqual_ivec2_frag ES2-CTS.gtf.GL.notEqual.notEqual_ivec3_frag ES2-CTS.gtf.GL.notEqual.notEqual_vec2_frag ES2-CTS.gtf.GL.notEqual.notEqual_vec3_frag Bisect shows:b616164c95cb495ce43f6b61dc805ed911a85e89 is the first bad commit commit b616164c95cb495ce43f6b61dc805ed911a85e89 Author: Ian Romanick <ian.d.romanick@intel.com> AuthorDate: Fri Jan 23 17:31:12 2015 -0800 Commit: Ian Romanick <ian.d.romanick@intel.com> CommitDate: Thu Mar 19 10:21:08 2015 -0700 i965/fs: Emit better b2f of an expression on GEN4 and GEN5 On platforms that do not natively generate 0u and ~0u for Boolean results, b2f expressions that look like f = b2f(expr cmp 0) will generate better code by pretending the expression is f = ir_triop_sel(0.0, 1.0, expr cmp 0) This is because the last instruction of "expr" can generate the condition code for the "cmp 0". This avoids having to do the "-(b & 1)" trick to generate 0u or ~0u for the Boolean result. This means code like mov(16) g16<1>F 1F mul.ge.f0(16) null g6<8,8,1>F g14<8,8,1>F (+f0) sel(16) m6<1>F g16<8,8,1>F 0F will be generated instead of mul(16) g2<1>F g12<8,8,1>F g4<8,8,1>F cmp.ge.f0(16) g2<1>D g4<8,8,1>F 0F and(16) g4<1>D g2<8,8,1>D 1D and(16) m6<1>D -g4<8,8,1>D 0x3f800000UD v2: When the comparison is either == 0.0 or != 0.0 use the knowledge that the true (or false) case already results in zero would allow better code generation by possibly avoiding a load-immediate instruction. v3: Apply the optimization even when neither comparitor is zero. Shader-db results: GM45 (0x2A42): total instructions in shared programs: 3551002 -> 3550829 (-0.00%) instructions in affected programs: 33269 -> 33096 (-0.52%) helped: 121 Iron Lake (0x0046): total instructions in shared programs: 4993327 -> 4993146 (-0.00%) instructions in affected programs: 34199 -> 34018 (-0.53%) helped: 129 No change on other platforms. output: dEQP Core GL-CTS-2.0 (0x0052484b) starting.. target implementation = 'X11' Test case 'ES2-CTS.gtf.GL.equal.equal_vec2_frag'.. #+ GTF/GL/equal/equal_vec2_frag.shader1.ppm and GTF/GL/equal/equal_vec2_frag.shader2.ppm are different Fail (Fail) DONE! Test run totals: Passed: 0/1 (0.00%) Failed: 1/1 (100.00%) Not supported: 0/1 (0.00%) Warnings: 0/1 (0.00%) Reproduce steps: ---------------- 1. start X 2. ./glcts --deqp-case=ES2-CTS.gtf.GL.equal.equal_vec2_frag
There is a patch on the mailing list that should fix this issue. Please test. http://lists.freedesktop.org/archives/mesa-dev/2015-March/080368.html
(In reply to Ian Romanick from comment #1) > There is a patch on the mailing list that should fix this issue. Please > test. > > http://lists.freedesktop.org/archives/mesa-dev/2015-March/080368.html Apply this patch ,it still fails. output: dEQP Core GL-CTS-2.0 (0x0052484b) starting.. target implementation = 'X11' Test case 'ES2-CTS.gtf.GL.equal.equal_vec2_frag'.. #+ GTF/GL/equal/equal_vec2_frag.shader1.ppm and GTF/GL/equal/equal_vec2_frag.shader2.ppm are different Fail (Fail) DONE! Test run totals: Passed: 0/1 (0.00%) Failed: 1/1 (100.00%) Not supported: 0/1 (0.00%) Warnings: 0/1 (0.00%)
Does just ES2-CTS.gtf.GL.equal.equal_vec3_frag fail? What about the various notEqual tests from the original report?
Also... I sent two tests to the piglit list. Could you try them on Iron Lake with and without the Mesa patch? http://patchwork.freedesktop.org/patch/45477/ http://patchwork.freedesktop.org/patch/45480/ I don't have very easy access to an Iron Lake system right now, so I had to try reproducing the bug on a different system. I was able to get these tests to fail on Ivy Bridge without the patch, and they both pass with the patch. Thanks.
On ILK: Without the patch, both 2 cases fail.With the patch, fs-notEqual-of-expression.shader_test works well. fs-equal-of-expression.shader_test still fails. On IVB, these 2 cases always pass without/with patch. With patch output: [root@x-pk5 piglit]# bin/shader_runner /GFX/Test/Piglit/piglit/tests/spec/glsl-1.10/execution/fs-notEqual-of-expression.shader_test -auto PIGLIT: {"result": "pass" } [root@x-pk5 piglit]# bin/shader_runner /GFX/Test/Piglit/piglit/tests/spec/glsl-1.10/execution/fs-equal-of-expression.shader_test -auto Probe color at (0,0) Expected: 0.000000 1.000000 0.000000 1.000000 Observed: 0.000000 1.000000 1.000000 1.000000 PIGLIT: {"result": "fail" } Without patch output: [root@x-pk5 piglit]# bin/shader_runner /GFX/Test/Piglit/piglit/tests/spec/glsl-1.10/execution/fs-equal-of-expression.shader_test -auto Probe color at (0,0) Expected: 0.000000 1.000000 0.000000 1.000000 Observed: 0.000000 1.000000 1.000000 1.000000 PIGLIT: {"result": "fail" } [root@x-pk5 piglit]# bin/shader_runner /GFX/Test/Piglit/piglit/tests/spec/glsl-1.10/execution/fs-notEqual-of-expression.shader_test -auto Probe color at (0,0) Expected: 0.000000 1.000000 0.000000 1.000000 Observed: 0.000000 1.000000 1.000000 1.000000 PIGLIT: {"result": "fail" }
Updated patch: http://lists.freedesktop.org/archives/mesa-dev/2015-April/081416.html Please test. Thanks.
(In reply to Ian Romanick from comment #6) > Updated patch: > > http://lists.freedesktop.org/archives/mesa-dev/2015-April/081416.html > > Please test. Thanks. Fixed by this patch.
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.