The following dEQP tests regressed on SNB with a recent patch series: piglit.deqp-gles3.functional.shaders.random.trigonometric.vertex.1 mesa c951bb83056724df02ba7e6fe2dfa720c0f45c1f piglit.deqp-gles2.functional.shaders.random.trigonometric.vertex.1 mesa c3f8cde964f9850c86469a06d5eedf4e783cbf5c piglit.deqp-gles3.functional.shaders.random.all_features.vertex.73 mesa cadd7dd384b33a779d46bd664f456bed4a21a5b7 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp:178: void brw::check_gen6_math_src_arg(brw_reg): Assertion `src.dw1.bits.swizzle == (((0)<<0) | ((1)<<2) | ((2)<<4) | ((3)<<6))' failed.
I'm pretty sure I know exactly what's going on here. NIR has swizzles for all ALU instructions, but i965 can't swizzle some (maybe all?) math instructions. The easiest fix would be to simply make emit_math emit an additional MOV if there is a non-trivial swizzle. The reason this showed up as a regression is probably that we're doing better coalescing now than we were before. The bug was present, we just weren't tickling it. I'm re-assigning this to one of the Igalia people. DISCLAIMER: The above is entirely off the top of my head. I haven't looked at the docs or the actual shaders. Mark: As a side-note, we should probably be running dEQP on a HSW as well as BDW. That way we get their merciless shader tests on vec4 as well as FS. That would have caught this one earlier.
(In reply to Jason Ekstrand from comment #1) > I'm pretty sure I know exactly what's going on here. NIR has swizzles for > all ALU instructions, but i965 can't swizzle some (maybe all?) math > instructions. The easiest fix would be to simply make emit_math emit an > additional MOV if there is a non-trivial swizzle. The reason this showed up > as a regression is probably that we're doing better coalescing now than we > were before. The bug was present, we just weren't tickling it. I'm > re-assigning this to one of the Igalia people. Thanks for the tip. I will be taking a look at this.
Jason, can you explain why enabling dEQP on HSW would have caught this? It only regressed on SNB, according to my tests.
(In reply to Jason Ekstrand from comment #1) > I'm pretty sure I know exactly what's going on here. NIR has swizzles for > all ALU instructions, but i965 can't swizzle some (maybe all?) math > instructions. The easiest fix would be to simply make emit_math emit an > additional MOV if there is a non-trivial swizzle. The reason this showed up > as a regression is probably that we're doing better coalescing now than we > were before. The bug was present, we just weren't tickling it. I'm > re-assigning this to one of the Igalia people. We are currently emitting an additional MOV in emit_math if there is a non-trivial swizzle (gen6). However, as you said, register coalescing is certainly involved because it removes that MOV instruction. I wrote patch to prevent register coalescing when non-trivial swizzling is required in gen 6 math instructions. You can find the patch here: http://lists.freedesktop.org/archives/mesa-dev/2015-September/094889.html It fixes the 3 listed dEQP regressions and I have checked that it does not introduce new Piglit or dEQP GLES 3.0 regressions in SandyBridge. I have not had time to run dEQP GLES 2.0 tests though, I can do it on Monday.
Fix pushed! commit f2e75ac88a92ab2180de576aca298929cfce03f2
This bug has been fixed for a while now. Closing.
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.