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
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.
Ok, I've tested steam/GOG/wine/wine+nine all have this issue. I run out of ideas.
Can you test with latest master/trunk of both Mesa and LLVM? The versions you mention in Comment #1 are all quite old.
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.
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.
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)
Ok, I think I've found big part of this problem: author Marek Olšák <marek.olsak@amd.com> 2016-09-13 15:33:23 (GMT) committer Marek Olšák <marek.olsak@amd.com> 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
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.
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.
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.
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.
Same bug happens with gallium nine on tonga.
This series from Marek fixes the issue for me (RX 470): https://lists.freedesktop.org/archives/mesa-dev/2017-January/139432.html
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
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.
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.
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).
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.
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
I confirm that Marek's patch fixes Witcher 2.
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
(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%
The Witcher 3 in Wine is affected by a very similar issue: https://bugs.winehq.org/show_bug.cgi?id=43786 And actually setting glsl_correct_derivatives_after_discard=true helps as well, though it costs some performance.
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.