Hi all, Clearly, the Vulkan CTS inherited the thoroughness of dEQP's ES tests in this area, because the first two fixes were already done for radv.
The last fix is for a quite amusing issue. One of the dEQP tests chooses a viewport pseudo-randomly for rendering a sqare. With some of the pseudo-random choices, one pixel at the corner of one of the triangles ends up in a quad with three helper invocations, one of which lies outside the triangle in such a way that its layer index becomes smaller than -0.5. So its layer is rounded to -1. This triggers a hardware bug that exists on <= VI, where clamping of a negative cube map layer number causes the face number to be corrupted. This in turn messes with the automatic LOD calculation. We end up choosing the wrong mip level and failing the test. Wave VGPR dumping definitely helped to make sense of that one :) Please review! Thanks, Nicolai -- src/amd/common/ac_llvm_build.c | 42 ++++++- src/amd/common/ac_llvm_build.h | 10 +- src/amd/common/ac_nir_to_llvm.c | 13 +- src/gallium/drivers/radeonsi/si_pipe.c | 1 - src/gallium/drivers/radeonsi/si_pipe.h | 1 - src/gallium/drivers/radeonsi/si_shader.c | 3 +- .../drivers/radeonsi/si_shader_tgsi_mem.c | 107 ++++++++++++++++- .../drivers/radeonsi/si_shader_tgsi_setup.c | 2 +- 8 files changed, 152 insertions(+), 27 deletions(-) _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev