|Summary:||Witcher 2: objects are black when changing lod on Radeon Pitcairn|
|Component:||Drivers/Gallium/radeonsi||Assignee:||Default DRI bug account <dri-devel>|
|Status:||RESOLVED FIXED||QA Contact:||Default DRI bug account <dri-devel>|
|Priority:||medium||CC:||arek.rusi, edmondo.tommasina, pasrospa|
|i915 platform:||i915 features:|
|Bug Depends on:|
Description almos 2016-10-13 21:43:09 UTC
When walking around basically everything changes level of detail all the time, and when they do they are black for a few frames. This looks very nasty. I guess the texture upload is not as fast as the game expects. Or maybe the fade transition between the lods is bugged somehow? I tried to capture an apitrace, but when replaying glretrace only shows uninitialized window content. HW: R9 270x
Comment 1 Arek Ruśniak 2016-10-23 11:24:41 UTC
Hi, i am pretty sure few months ago worked as it should. i've tried to bisected but it not easy or maybe it's almost impossible find good one kernel/LLVM/mesa/libdrm/xorg/glamor.. So i installed fresh debian 8: kernel 3.16 LLVM 3.5 mesa 10.6 (IIRC) xorg 1.16.x and issue still here, maybe this is game bug not mesa or i've got blind i have this issue on steam, i can test gog version later. And there is beta_public_linux on steam so can be worth to test as well i965 & r600 works good Tested on verde, juniper and haswell.
Comment 2 Arek Ruśniak 2016-10-26 20:24:18 UTC
Ok, I've tested steam/GOG/wine/wine+nine all have this issue. I run out of ideas.
Comment 3 Nicolai Hähnle 2016-11-04 10:14:46 UTC
Can you test with latest master/trunk of both Mesa and LLVM? The versions you mention in Comment #1 are all quite old.
Comment 4 almos 2016-11-04 13:07:24 UTC
I forgot to mention that I reported this against Mesa 12.0.3 and LLVM 3.9.0, but the situation was the same when I played the game earlier with Mesa 11.x. I also tried 13.0-dev, but aside from some increase in performance (the worst part is when defending the wall in Vergen at the end of chapter 2), I saw no change in visuals. In the game's launcher there is an option to select between OpenGL 2.1 and 3.2, but I see absolutely no difference between them.
Comment 5 Christian Lanig 2016-11-09 21:37:19 UTC
I can confirm this bug. When the game changes the textures it switches to a black object without any texture at first. As a partly workaround I suggest to change the following options in your User.ini: TextureMemoryBudget MeshDistanceScale The texture memory budget should be slightly below the maximum amount of VRAM, for example 7680 would be reasonable for a 8GiB- card. The more you increase the mesh distance the further the textures get changed. So when I set it to 99.9 it's not that distracting anymore(changing textures are smaller then of course). The file is located at ~/.local/share/cdprojektred/witcher2/GameDocuments/Witcher\ 2/config/User.ini Sadly the grass is not included in this value so you might still see annoying grass behaviour. So finally we have about three bugs, the textures aren't switched correctly which is perhaps a driver issue but the LoD behaviour of the engine is also really stupid, especially when it extremely decreases within something like 2 metres from the char on the highest settings as long as no changes are made in the User.ini. And finally not being able to change the grass settings.
Comment 6 Pablo 2016-11-16 08:20:30 UTC
This bug has also been reported in the game's github: https://github.com/virtual-programming/witcher2-linux/issues/170 It includes a video of the issue and apparently it is a known issue with radeonsi. My setup: RX480 + Linux 4.8 + Mesa 13.0.1 (Debian experimental)
Comment 7 Arek Ruśniak 2016-11-25 12:54:47 UTC
Ok, I think I've found big part of this problem: author Marek Olšák <email@example.com> 2016-09-13 15:33:23 (GMT) committer Marek Olšák <firstname.lastname@example.org> 2016-09-14 10:33:00 (GMT) commit ab29788250a705eb0dd517cb3d38f37f944eb8ad (patch) radeonsi: reload PS inputs with direct indexing at each use (v2) The LLVM compiler can CSE interp intrinsics thanks to LLVMReadNoneAttribute. 26011 shaders in 14651 tests Totals: SGPRS: 1146340 -> 1132676 (-1.19 %) VGPRS: 727371 -> 711730 (-2.15 %) Spilled SGPRs: 2218 -> 2078 (-6.31 %) Spilled VGPRs: 369 -> 369 (0.00 %) Scratch VGPRs: 1344 -> 1344 (0.00 %) dwords per thread Code Size: 35841268 -> 36009732 (0.47 %) bytes LDS: 767 -> 767 (0.00 %) blocks Max Waves: 222559 -> 224779 (1.00 %) Wait states: 0 -> 0 (0.00 %) v2: don't call load_input for fragment shaders in emit_declaration videos from "last good" and "first bad": https://youtu.be/X3Zqb-cYssg https://youtu.be/73X9SVf6_1g
Comment 8 Arek Ruśniak 2016-11-25 13:03:02 UTC
I can't provide apitrace or any kind of usefull things for witcher but I've found regression in unigine-valley for the same commit If you think it can help I can provide apirace form valley.
Comment 9 Arek Ruśniak 2016-11-25 13:36:04 UTC
I've forgot to mention, in both case I've build mesa against LLVM 3.9.0 (official arch packages) I cannot simply revert ab29788250a705eb0dd517cb3d38f37f944eb8ad I had compile errors with LLVM 4.0, didn't try 3.8.x.
Comment 10 Christian Lanig 2016-11-27 01:07:14 UTC
The bug pretty nicely demonstrating how textures load might lead to a useful way to debug engines while I don't see any performance impact? I'm no game developer and I don't know whether the behavior can be reproduced for any game but I got the idea that just turning a switch like a dev driver mode to make the loading of textures this clear is much easier than writing his own.
Comment 11 Shmerl 2016-12-11 21:10:56 UTC
I have the same problem with Mesa 13.0.2 / radeonsi on RX 480 (reported it here: https://github.com/virtual-programming/witcher2-linux/issues/175 ). See attached video there for example of this behavior.
Comment 12 Axel Davy 2016-12-18 00:57:39 UTC
Same bug happens with gallium nine on tonga.
Comment 13 Edmondo Tommasina 2017-01-03 22:18:54 UTC
This series from Marek fixes the issue for me (RX 470): https://lists.freedesktop.org/archives/mesa-dev/2017-January/139432.html
Comment 14 Arek Ruśniak 2017-01-04 00:42:25 UTC
Edmondo, these patches made big difference but not resolved all "black transition". Some wooden surfaces flickers still (rx470 too) But It's still better then before commit ab29788250a705eb0dd517cb3d38f37f944eb8ad I can record this later
Comment 15 almos 2017-01-05 17:54:53 UTC
I confirm that Marek's patch series greatly improves the situation, but the black transitions are not eliminated completely. The foliage is good now, but the rocks are still bad.
Comment 16 Edmondo Tommasina 2017-01-05 23:54:28 UTC
Marek sent a v2 of the patch to the mailing list: https://lists.freedesktop.org/archives/mesa-dev/2017-January/139640.html I tested both v1 and v2 a bit more and I agree with you Arek and almos: the patch fixes a lot of black transitions but not all of them.
Comment 17 Marek Olšák 2017-01-06 00:03:49 UTC
The remaining bug can be an instruction scheduling issue: v_interp is moved outside of the WQM or moved after the KILL opcode (which can break the WQM) or moved into a branch (same issue).
Comment 18 Shmerl 2017-01-25 03:10:38 UTC
I compiled the latest Mesa master (git-2ab2be092d) which includes the recent fix from Marek: https://cgit.freedesktop.org/mesa/mesa/commit/?id=59c5da40ed2c6c56e29b562c2ee2c8705f28738b and the bug is mostly gone, but it still happens in few areas for example on the brick city walls and gates in Flotsam.
Comment 19 Edmondo Tommasina 2017-06-21 20:52:00 UTC
Marek sent a series of patches to the mailing list that could be interesting to fix the black transition issue for Witcher 2: https://lists.freedesktop.org/archives/mesa-dev/2017-June/160177.html I sent a patch to the list enabling the drirc option for Witcher 2 and it seems to fix the black transitions problems for me: https://lists.freedesktop.org/archives/mesa-dev/2017-June/160291.html
Comment 20 almos 2017-06-23 13:47:21 UTC
I confirm that Marek's patch fixes Witcher 2.
Comment 21 Shmerl 2017-06-23 19:46:21 UTC
It's now in master. It should eventually land in /etc/drirc in distros, but until then, build Mesa from source and set this variable when running the game: glsl_correct_derivatives_after_discard=true
Comment 22 Gregor Münch 2017-06-26 12:37:47 UTC
(In reply to Shmerl from comment #21) > It's now in master. It should eventually land in /etc/drirc in distros, but > until then, build Mesa from source and set this variable when running the > game: > > glsl_correct_derivatives_after_discard=true Not needed, Edmondos patch sets this automatically. https://cgit.freedesktop.org/mesa/mesa/commit/?id=2ea16f08f3f57ce32a2912ddd0ed74027a89a547 If someone wants old behavior back set in game's launch option: glsl_correct_derivatives_after_discard=false %command%