Created attachment 125773 [details] Screenshot showing the bug (frame 89) With radeonsi the chapter select screen in Spec Ops: The Line has black squares that should not be there. I have not observed this bug elsewhere in the game (but haven't played through the whole game using radeonsi). The number of squares increases with a higher texture quality setting. The number and positions of the squares only changes when the camera moves. The chapter select screen renders fine using the amdgpu-pro driver - tested with version 16.30.3.306809 running on the upstream amdgpu kernel module. Apitrace: http://constexpr.org/tmp/SpecOps-radeonsi.trace.xz (70 MiB) This bug seems to be caused by pixels with NaN values that make it into the framebuffer and are extended to larger squares by a later post-processing pass: After draw call 1441551, pixel (875, 573) of the COLOR0 attachment has RGB components set to NaN. GPU: R9 380X (tonga) Kernel: 4.7.0-gentoo Mesa: git-561fd22 LLVM: r278309
Created attachment 125774 [details] Screenshot showing the bug (frame 91) May or may not be related to bug #90481 - I haven't seen any gpu lockups or crashes in the menu.
Hi Daniel, thank you for the detailed report and the initial investigation! I can indeed reproduce this (including the NaN values) on Polaris.
Created attachment 126172 [details] Problematic fragment shader Okay, so here's a bit more detail of what is happening: the attached fragment shader (shader object 31) samples a 2D vector from PSampler2 (texture object 3153) and does some computations on it involving inversesqrt, under the assumption that the dot product of the vector is <= 1. This is false: looking at level 0 of texture 3153 reveals e.g. a unorm value (142, 255) at texel 155,263. The likely cause here is that this is a port from D3D, which specifies that rsq should take the absolute value of its argument, to GLSL, which says that inversesqrt is undefined for values <= 0.
I've raised this issue with Virtual Programming.
If it's undefined, doing abs is probably a good idea to at least reduce the number of bug reports.
A possible fix here: https://lists.freedesktop.org/archives/mesa-dev/2017-January/139686.html
People might be interested by https://github.com/virtual-programming/specops-linux/issues/20
(In reply to Samuel Pitoiset from comment #6) > A possible fix here: > https://lists.freedesktop.org/archives/mesa-dev/2017-January/139686.html I get a build failure after applying this patch: si_shader_tgsi_alu.c: In function ‘emit_rsq’: si_shader_tgsi_alu.c:759:43: error: ‘TGSI_OPCODE_ABS’ undeclared (first use in this function) abs = lp_build_emit_llvm_unary(bld_base, TGSI_OPCODE_ABS, ^~~~~~~~~~~~~~~ si_shader_tgsi_alu.c:759:43: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [Makefile:701: si_shader_tgsi_alu.lo] Error 1
Makes sense. TGSI_OPCODE_ABS has been removed after this patch, but it fixes the issue (I tested myself). The patch is still pending for some reasons, I will let you know when something change.
Should be fixed with https://cgit.freedesktop.org/mesa/mesa/commit/?id=e11049f2c367192dfb1540855f6571a5e29b77ec.
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.