Hardware: BSW RVP Bug detailed description =========== The following drawElements tests appear to have regressed between Mesa 10.5.0 and 10.6.0 with the same failure signature on BSW: - dEQP-GLES3.functional.shaders.invariance.highp.loop_0 - dEQP-GLES3.functional.shaders.invariance.highp.loop_1 - dEQP-GLES3.functional.shaders.invariance.lowp.loop_0 - dEQP-GLES3.functional.shaders.invariance.lowp.loop_1 - dEQP-GLES3.functional.shaders.invariance.mediump.loop_0 - dEQP-GLES3.functional.shaders.invariance.mediump.loop_1 Cases where the test passed: - ChromeOS on BSW w/ mid-November commit of Mesa (on platforms Haswell, Baytrail, Broadwell and Braswell - not sure of the commit on this) - Upstream Linux (bsw system) using Mesa commit from 2014-11-24; commit ID: c88385603ae8d983314b736a9459bbf7d002cf11 Cases where the test failed: - ChromeOS on BSW w/ mesa commit we were trying to move to (c2a0600 i965: Don't set NirOptions for stages that will use the vec4 backend) - Upstream Linux (bsw system) using the mesa commit we were trying to move to - Upstream Linux (bsw system) using current ToT mesa (as of 5/20/15) Reproduce Steps ============== 1. Run indicated drawElements tests with indicated version of Mesa or ToT Mesa 2. Compare test results against older (mid-November) Mesa commit Expected Result ============= No failure with current ToT Mesa Actual Result =========== Expecting only green or background colored pixels. Invalid pixels found (fragments from first render pass found). Variance detectedDetected variance between two invariant values.
These all pass for me with Mesa master.
They actually pass for me with c2a0600d5b0645533ba442b5ab879b23c2564a4d, though, too...so I guess I'm just not able to reproduce this.
I can reproduce this bug by BSW (VGA compatible controller: Intel Corporation Device 22b1 (rev 21)) Kernel:4.1.0-rc7_kcloud_1845ca_20150612+ Bisect shows: ee5fb8d1ba7f50ed94e1a34fa0f6e15a0588145e is the first bad commit. commit ee5fb8d1ba7f50ed94e1a34fa0f6e15a0588145e author Kristian Høgsberg <krh@bitplanet.net> 2014-10-21 06:29:41 (GMT) committer Kristian Høgsberg <krh@bitplanet.net> 2014-12-10 20:29:27 (GMT) commit ee5fb8d1ba7f50ed94e1a34fa0f6e15a0588145e (patch) tree 303ad7ac28769482c37c27fdc448231f9cd9c052 parent 7ff457b93028d1884c7952080edd919008edf141 (diff) i965: Generate vs code using scalar backend for BDW+ With everything in place, we can now use the scalar backend compiler for vertex shaders on BDW+. We make scalar vertex shaders the default on BDW+ but add a new vec4vs debug option to force the vec4 backend. No piglit regressions. Performance impact is minimal, I see a ~1.5 improvement on the T-Rex GLBenchmark case, but in general it's in the noise. Some of our internal synthetic, vs bounded benchmarks show great improvement, 20%-40% in some cases, but real-world cases are mostly unaffected. Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Kristian Kristensen looked into this and reported the following: Ok, know what's going on with this bug now. The test tests the invariance keyword by trying to provoke rounding errors coming from different code paths computing the same result. Different levels of optimization may reuse common subexpression results or rewrite a mul+add to a mad, resulting in the same GLSL code computing getting compiled to different hw instructions. A driver that support the GLSL invariant keyword will make sure that different shaders always compute the same value the same way. On drivers (like mesa) that don't support invariance, the test may still pass, and as such, the fact that the test passed in the past doesn't make this a regression. When we switched mesa to use SIMD8 VS (the commit in quesstion), we started using a different optimizer for the vertex shader code, which optimizes the shaders enough that we get different results for the depth values. In short: not a regression, the test passed previously because it's hard to consistently trigger the error condition. Kristian
*** This bug has been marked as a duplicate of bug 94449 ***
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.