Mesa bbf8291 caused the following regressions: functional.shaders.loops.do_while_dynamic_iterations.vector_counter_vertex functional.shaders.loops.for_dynamic_iterations.vector_counter_vertex functional.shaders.loops.while_dynamic_iterations.vector_counter_vertex Both gles2 and gles3 variants regressed when NIR was enabled. BDW did not encounter these regressions.
After a bit more analysis, this bug appears to be a coalescing bug. Thanks to Kristian for spotting the broken swizzle! What happens is that NIR gives us vec1 ssa_9 = imul ssa_7, ssa_8 vec4 ssa_10 = vec4 ssa_2, ssa_2.y, ssa_9, ssa_2.z in SSA which then becomes r7 = imul r5, r6 r8.xyw = imov ssa_2.xyz r8.z = imov r7.x When we go out of SSA. This then turns into 9: mul acc0:D, vgrf5.xyzw:D, u0.xyzw:D 10: mach null:D, vgrf5.xyzw:D, u0.xyzw:D 11: mov vgrf7.0.x:D, acc0.xxxx:D 12: mov vgrf8.0.xyw:D, vgrf13.xyxz:D 13: mov vgrf8.0.z:D, vgrf7.xyxw:D which register coalesce happily turns into 9: mul acc0:D, vgrf5.xyzw:D, u0.xyzw:D 10: mach null:D, vgrf5.xyzw:D, u0.xyzw:D 11: mov vgrf8.0.z:D, acc0.xxxx:D Note that we completely miss the fact that line 13 above moves the x channel to the z channel and we just coalesce to mask out all but z. The result is that mul/mach write to .x but we read from .z. If I run the test with register coalescing turned off, it passes.
This bug *should* be fixed by: http://lists.freedesktop.org/archives/mesa-dev/2015-September/094115.html On 32-bit systems, you may also need two of Antia's patches: http://lists.freedesktop.org/archives/mesa-dev/2015-August/091699.html http://lists.freedesktop.org/archives/mesa-dev/2015-August/092474.html
the one patch definitely fixes the dEQP tests referenced in this bug. There were a couple of 32 bit regressions on bsw, that may be due to leaving out Anita's patches.
I just pushed the two patches. Closing this bug as 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.