System Environment: -------------------------- Arch: i386 Platform: Pineview Libdrm: (master)2.4.44-9-g96e90aabc4c0238de2f2d245899f991a3b996587 Mesa: (master)888fc7a89197972aac614fc19d1c82ed1adbb3f2 Xserver:(master)xorg-server-1.14.99.1-81-g2f1aedcaed8fd99b823d451bf1fb02330c078f67 Xf86_video_intel:(master)2.21.6-31-g2217f6356b53263b6ce8f92b5c29c0614d4ef2a5 Cairo: (master)728e58e60f89076f626329ee3f006f011783f90b Libva: (staging)0139a11ba23f8b2aa0d2ed36336c4df23d54390c Libva_intel_driver:(staging)0a5cfdab47c788569feb0a3e4293906687523f88 Kernel: (drm-intel-nightly) fa643cb2d17c011fdddd5e0cc8fc808e097dc5bb Bug detailed description: ------------------------- It fails on pineview with mesa master branch. It works well on 9.1 branch. Following cases also fail, and have same bisect commit: spec_glsl-1.10_execution_variable-indexing_fs-temp-array-mat4-col-row-wr spec_glsl-1.20_execution_variable-indexing_fs-temp-array-mat4-col-row-wr spec_glsl-1.20_execution_variable-indexing_fs-temp-mat4-col-row-wr Bisect shows:3acb21517b3a23cf1044531e96d9741bd1c122c3 is the first bad commit. commit 3acb21517b3a23cf1044531e96d9741bd1c122c3 Author: Ian Romanick <ian.d.romanick@intel.com> AuthorDate: Fri Mar 15 18:08:22 2013 -0700 Commit: Ian Romanick <ian.d.romanick@intel.com> CommitDate: Mon May 13 12:05:19 2013 -0700 glsl: Generate ir_binop_vector_extract for indexing of vectors Now ir_dereference_array of a vector will never occur in the RHS of an expression. v2: Add back the { } around the if-statement body to make it more readable. Suggested by Eric. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> output: Probe at (10,10) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (10,25) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (10,40) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (10,55) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (25,10) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (25,25) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (25,40) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (25,55) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (40,10) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (40,25) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (40,40) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (40,55) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (55,10) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (55,25) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (55,40) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (55,55) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 PIGLIT: {'result': 'fail' } Reproduce steps: ---------------- 1. xinit 2. ./bin/shader_runner tests/spec/glsl-1.10/execution/variable-indexing/fs-temp-mat4-col-row-wr.shader_test -auto
Ian, can you reproduce?
I can confirm the bisect - it works before that commit, and fails on it. I also observed that it works with either no_rast=true or LIBGL_ALWAYS_SOFTWARE=1, so presumably the Mesa IR being generated is good. Sounds like the i915 assembly is bad. I don't plan on investigating further, though...the i915c driver confuses me.
I suspect the problem is changing the compiler to not generate the vectorized compares makes it take too many instructions for i915. That's just a hunch, though. I will take care of this for 9.2.
It turned out to be the opposite of my intuition. The changes in the patch caused *more* tests to run in hardware on i915. The problem is the tests require more precision that i915 can deliver with its 24-bit floats. I have sent a patch to the piglit mailing list to relax the precision requirement (these tests are not about the precision of the distance() function anyway!) and a patch to the Mesa list that makes even more tests run in hardware. http://lists.freedesktop.org/archives/piglit/2013-August/006903.html http://lists.freedesktop.org/archives/mesa-dev/2013-August/043650.html I am removing this bug from the release tracker because it's not a real regression.
Please confirm that this is seen on an SNB or newer platform.
(In reply to comment #5) > Please confirm that this is seen on an SNB or newer platform. It passes on all platforms. Test on latest mesa master branch.
Fixed.
Verified.
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.