I’ve recently built a new gaming rig with an R7 1700 and an R9 Fury. The game Control works fine with vkd3d under Wine, but Horizon Zero Dawn shows some really weird vegetation glitches. The suggested fix is to run HZD with Proton Experimental. Problem being that this is an Epic copy of HZD downloaded via the Heroic Game Launcher.
So Heroic does auto-detect Proton Experimental, but HZD just dies when launched with Proton Exp. Not really sure why. Have had a couple of suggestions to try running it thru Lutris + Epic Game Launcher + Proton, but I’m not sure how well that works. Anyone here try it?
The fix was not to run the game with Proton, but rather some arcane environment variables buried in the protondb.com compatibility reports:
AMD_VULKAN_ICD=RADV RADV_DEBUG=llvm VKD3D_CONFIG=no_upload_hvv
This eliminated the weird ghosting/smearing visible on the vegetation textures.
2 Likes
Does Proton works well outside of Seam? In any case Glorious Eggroll has a project that brings all the Proton features plus some extra stuff to non Steam environments.
1 Like
Some of the compatibility reports indicated that Proton Experimental works best with HZD. However, even when I loaded the game with Lutris + Proton Experimental I still had the crazy vegetation ghosting.
Digging even deeper into the reports I found those values, and they did straighten out the ghosting. Only ‘downside’ was that I had to enable ‘gamemode’.
So going through these options I’m not really sure what’s really helping you there…
AMD_VULKAN_ICD=RADV RADV should be used with an R9 Fury by default anyway
RADV_DEBUG=llvm This switches the Shader compiler from ACO to LLVM and I can hardly imagine it’s going to be that, plus ACO has quite a bit better performance.
VKD3D_CONFIG=no_upload_hvv this is probably the key, although I’m not sure why that would make a difference as per the documentation:
-
no_upload_hvv - Blocks any attempt to use host-visible VRAM (large/resizable BAR) for the UPLOAD heap. May free up vital VRAM in certain critical situations, at cost of lower GPU performance. A fraction of VRAM is reserved for resizable BAR allocations either way, so it should not be a real issue even on lower VRAM cards.
2 Likes
I noticed a drastic decrease in performance when using these variables, so thinking the ‘debug’ parameter might be causing excessive logging, I took “RADV_DEBUG=llvm” out of the launch variables. The ghosting came right back. Whatever it does it’s a key component to avoiding the ghosting.
I compensated for the lower performance by enabling Feral’s gamemode. That got me back up to around 55 - 60 fps.
EDIT: If you don’t mind sharing, where’d you find the documentation for those environment variables? I assume they’re amdgpu related.
No it’s got nothing to do with logging. This is purely a switch to LLVM as the shader compiler.
Until a couple years ago everything was using LLVM. ACO was introduced by Valve maybe 2-ish years ago and has been the default for AMD cards since about a year or so. It used to be that ACO had to be enabled with RADV_PERFTEST=aco, then when ACO became the default in the testing branch it could be disabled with RADV_PERFTEST=llvm (re-enabling LLVM instead). And when it got its official release with mesa, it got moved to RADV_DEBUG (why that is I can only speculate, I’m assuming that PERFTEST is reserved for experimental features while DEBUG is meant for testing something different when something doesn’t work properly).
Interesting, I guess ACO is just not fully supported on those older cards then.
The First option is an amdgpu option to choose the ICD loader, you can find them on the arch wiki and others (not sure where the “real” documentation is).
The second is an option to RADV to decide which shader compiler to use. Documentation is on the mesa website:
https://docs.mesa3d.org/envvars.html#radv-driver-environment-variables
The third one is an option for VKD3D (which handles the actual DirectX to Vulkan translation). The documentation is on the GitHub:
2 Likes
Thanks for all the info. Might be instructive to play with the ACO_DEBUG variable and see if toggling any particular ACO feature off fixes the ghosting.
Unfortunately I’m not really sure where the correct place is to report bugs with ACO… if they are to be raised directly with Mesa or with Valve.
The original work for ACO was done here:
But that repo doesn’t seem to be maintained anymore.
Hmm wondering if AMDVLK + LLVM might work better/faster with my old, oddball Fury. AMDVLK was originally derived from an AMD codebase, was it not?
AMDVLK only works with the Pro driver I think?
Whether it’s derived from anything I don’t know but it’s just the Vulkan implementation, which doesn’t seem to be your issue since RADV works fine when using LLVM.
@mihawk90 Finally found a decent explanation of what AMDVLK is and how to use it:
In short it appears that AMDVLK and RADV can be used side by side with amdgpu but there’s usually little reason to because RADV is generally superior.
I may try anyway just in case the official AMD code works better with my old Fury.
1 Like