Created attachment 135457 [details] Fragment shader with workaround When compiling Mesa against LLVM >= 5.0, Nier:Automata shows lighting artifacts that are caused by a misbehaving 'if' in a fragment shader. Apitrace that shows the issue (2.5G, bz2-compressed): https://mega.nz/#!JaBD0IoT!yBekRb7ZmvsSY60mo0E7N6uwaYfp_KfRDlnQWL0-QOo I attached a copy of the fragment shader that causes the problem, but also includes a workaround. The file name for MESA_SHADER_READ_PATH is FS_feba74122c9590d1522b92bbec52d662ecd99012.glsl. The offending code is located at line 135: R1.x = uintBitsToFloat(floatBitsToUint(R0).y >= 0x4u ? 0xffffffffu : 0u); if (bool(floatBitsToUint(R1).x)) The artifacts go away when changing the original 'if' condition to the following: if (floatBitsToUint(R0).y >= 0x4u) This happens with both Mesa 17.2 and latest Mesa-git when compiling against LLVM 5.0 or later. This does *not* happen with LLVM 4.0.1. My GPU is an RX 480.
Created attachment 135458 [details] Frame 2400 with artifacts
Created attachment 135459 [details] Frame 2400 without artifacts
PS: While bug 102218 is not directly related to this one, that's another case where two shaders that *should* be functionally equivalent yield different results. In the second screenshot, workarounds for both issues are applied in order to obtain correct rendering.
Thanks for the very lucid bug report. I can reproduce this and am investigating.
I found another pair of equivalent expressions that produce different results. Working as expected: if ((floatBitsToUint(R0).y >= 0x4u ? 0xffffffffu : 0u) == 0xffffffffu) Showing artifacts: if ((floatBitsToUint(R0).y >= 0x4u ? 0xffffffffu : 0u) != 0u)
Thanks. To give you an update, this is a super subtle control flow handling bug in LLVM -- and the difference between the original shader and your modification at the LLVM input is merely that the sense of one branch is (correctly) inverted, leading LLVM down a subtly different path in the end. A sledge-hammer fix is quite simple, but I'm still thinking about how to get a better fix which doesn't pessimize a bunch of cases.
Created attachment 135749 [details] [review] patch for related issue
Created attachment 135750 [details] [review] patch to fix this issue Two patches for LLVM attached that fix the issue for me.
Thanks for looking into this. While these two patches certainly improve the situation significantly, they don't fix the issue entirely. The remaining artifacts are hardly noticable in the original apitrace, so I created another one (2.9G, bz2-compressed): https://mega.nz/#!FHxSgZjL!0MzRQhI6W6Lk0beTv9LrPxDWjNTQveDuXVq3Mz2s7-M Note that my original workaround still works with the LLVM patches applied. Tested with updated LLVM-git, revision accb337c76e.
Created attachment 135780 [details] Frame 2320 with patched LLVM
Created attachment 135781 [details] Frame 2800 with patched LLVM
Any news on this? The two LLVM patches have been pushed ~2 weeks ago. Can you still reproduce the issue? Thanks!
Created attachment 139196 [details] Video showing minor artifacts While it's a lot better, it's not fully fixed yet. I added a video to show a few artifacts, just look at the top middle area where the lightning jumps around. Created from this apitrace: http://www.mediafire.com/file/cch4roemrd2gi1f/AutomataArtifacts.7z
(In reply to Fabian Maurer from comment #13) > Created attachment 139196 [details] > Video showing minor artifacts > > While it's a lot better, it's not fully fixed yet. I added a video to show a > few artifacts, just look at the top middle area where the lightning jumps > around. > > Created from this apitrace: > http://www.mediafire.com/file/cch4roemrd2gi1f/AutomataArtifacts.7z Those artifacts from the video seem to be gone with recent Mesa (19.1-devel) and LLVM (9.0-devel). Can you confirm if that this is indeed 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.