AMD RX 6000 series driver issues & workarounds

[Morbad]

Update: Multiple confirmations that the 23.7.1 drivers have resolved VR rendering and performance issues. Leaving orbit/gravity lines as the remaining problem point (see below).

Update: @MrVaad has posted a 3DMigoto shader patch to address the aliased orbit/gravity lines here.

Update: Most of these workarounds should no longer be required. Crashes were addressed with the 22.10.3 and later drivers, while the atmospheric compositing shader issue that once required 3DMigoto to workaround was fixed by FDev in U14.

Make sure you can see file extensions in your file manager (e.g. File Explorer)!

Update: A partial fix has been implemented in the 22.10.3 drivers. The game will now load, generate terrain, and allow access to planet surfaces without having to disable double precision floats. However, the teal overlay present during certain on-foot conditions is still present and can still be fixed via 3DMigoto (or DXVK).

Starting with their May 2022 preview driver and continuing with the optional 22.5.2 through 22.10.2 drivers, AMD has included D3D11 optimizations that have caused a variety of compatibility issues with Odyssey, as roughly acknowledge by Frontier here. If you have any RX 6000 series AMD graphics adapter, or any other RDNA2/Navi2x part, running on Windows with post 22.5.1, you have probably encountered some of these symptoms and this thread may interest you.

As far as the community and I have been able to infer from our testing, these issues are due to how the new driver branch handles double precision (FP64) floats used in terrain generation, plus one of the game's shaders that, if left enabled, leaves a transparent bluish overlay on the screen during most on-foot scenes. Below, I will detail three workarounds to these problems, including the pros, cons, and implementations of each.

Disclaimer: Aside from reverting to older drivers, none of these workarounds are sanctioned by Frontier. If they don't work for you, or cause issues, don't complain to them, and don't burden support or the issue tracker with crash/bug reports resulting from their use.

Note: Different workarounds feature different files, some of which have the same names. Do not mix them.

Note #2: With regard to EDHM compatibility for workaround #2, reference Blavald's comments in post #7 and mine in post #23.

Note #3, regarding Steam overlay: There appears to be an unresolved issue with the last official 3Dmigoto binaries and the Steam overlay that may or may not result in issues with Workaround #2. If you encounter issues, either disable the Steam overlay when playing Odyssey, or use another workaround. See post #34.

Updates of note will be mentioned in post #2 and edited in here.

Workaround #1 -- Abstain from newer drivers.

Spoiler

Simply remaining on AMD's currently "recommended" 22.5.1 driver will clearly bypass the issues associated with newer driver releases.

Pros:

• No need for any of the more complex workarounds.
• Avoidance of new issues potentially introduced in other titles.

Cons:

• Losing out on the benefits of the newer driver branch, which include potentially significant D3D11 (including in Odyssey itself, with workaround #2) and OGL performance uplifts; support for newer games; and fixes to other bugs, as detailed in the respective release notes for each driver.
• The possibility that Windows Update decides that a newer, incompatible version is better and updates against your will.

Procedure:

• Either don't update your drivers, or remove any newer drivers (you may need to disconnect from the internet momentarily to prevent Windows Update from automatically reinstalling an undesirable driver version), and reinstall 22.5.1.
• Optionally disable Windows Update driver updates, globally, or the specific driver in question. There are multiple ways to do this (examples), but for the sake of brevity, I'll not detail them in this post.

Workaround #2 -- Address the specific D3D11 issues.

Spoiler

It is possible to disable FP64 in the game's AppConfig.xml and bypass the incompatible shader with 3Dmigoto, which will allow, as far as I have been able to observe, full functionality with the newest 22.8.2 driver release.

Update: As of 22.10.3 the AppConfig.xml change is no longer required. 3DMigoto is still recommended to correct the bugged shader.

Pros:

• You get all of the aforementioned benefits of the newest driver releases, including a meaningful increase to performance (~10% in my testing) in GPU limited areas of Odyssey itself.
• Should preserve VR (within Odyssey's limits) and borderless window functionality. Edit: Those having issues with VR should completely clear their caches and check the procedure in post #16.

Cons:

• You have to be able to read instructions, navigate the Windows file system, and edit a plaintext file.
• Patching the game or validating the game files will remove this workaround.
• There is no guarantee that future game updates will retain the same hash for the offending shader, in which case you'll have to use 3Dmigoto's hunting feature to identify the new hash yourself, or wait for someone else to find and document it.
• Conflict with 3Dmigoto and the Steam overlay can cause issues.

Procedure:

• Download the newest version of 3Dmigoto (currently v1.3.16) from here: https://github.com/bo3b/3Dmigoto/releases/
• Extract the d3d11.dll and d3dcompiler_46.dll files from "3Dmigoto-1.3.16.zip\x64\" to wherever you have Odyssey installed (the actual product directory with Odyssey's EliteDangerous64.exe inside it).
• Download the d3dx.ini.txt file I have attached to this post, remove the ".txt" part of the extension, and place the file in the game product directory noted above. I've disabled the relevant shader hash, and set 3Dmigoto to release mode (hunting disabled, for performance) in this file.
• In the same directory there is a file called AppConfig.xml. Open this in your favorite text editor (notepad will work) find the attribute "PermitNativeDoubles="true"" and change the "true" to "false", then save the file.
• Optionally clear the Windows and driver shader cache and delete GPUWorkTable.xml.
• Start the game.

Workaround #3 -- Bypass the D3D11 driver entirely by using a Vulkan translation layer!

Spoiler

DXVK will also resolve the issues with newer drivers, at the cost of some configuration and additional overhead. Touching actual game files is not required.

Pros:

• Potentially better performance in some CPU limited areas due to Vulkan having threaded command buffers.
• Some textures can actually look sharper due to a negative LOD bias that I've used to eliminate a crash on certain LOD transitions.
• Possibly less likely to be broken by game updates.

Cons:

• Also have to be able to read instructions, navigate the Windows file system, and optionally edit a plaintext file.
• Lower performance in GPU limited areas than D3D11 in the newest drivers, and about a wash with 22.5.1 and prior drivers.
• Required texture LOD bias adds a small amount of extra texture shimmering.
• Slightly increased GPU load in my tests (~7% higher power consumption in a given GPU limited scene), probably from overhead.
• Takes some game time/play to flesh out the DXVK cache, during which some stuttering will be evident. However, this only needs to happen once, unless you update the game, the drivers, DXVK itself, or delete the cache file.
• Breaks VR.
• Borderless window always on top.
• Modestly higher latency floor than native D3D11 (Radeon Anti-Lag doesn't seem to work either); rarely an issue.

Procedure:

• Download the newest version of DXVK (currently 1.10.3) from here: https://github.com/doitsujin/dxvk/releases (this is going to be a .tar.gz file, so you need an archival program that can handle this, I recommend 7-Zip, but many others will work).
• Extract d3d11.dll and dxgi.dll from "dxvk-1.10.3.tar.gz\dxvk-1.10.3.tar\dxvk-1.10.3\x64\" to wherever you have Odyssey installed (the actual product directory with Odyssey's EliteDangerous64.exe inside it).
• Download the dxvk.conf.txt file I have attached to this post, remove the ".txt" part of the extension, and place the file in the game product directory noted above.
• Optionally edit dxvk.conf and remove the "d3d11.samplerAnisotropy = 16" line, but only if you have a lower end card or were otherwise not using anisotropic filtering in your preferred game settings.
• Optionally clear the Windows and driver shader cache and delete GPUWorkTable.xml.
• Start the game.

ACKNOWLEDGEMENTS

• kakra@github for the elaboration on the emulateUMA function in DXVK.
• @Balvald for identifying the precise shader hash, enabling a more complete D3D11 workaround, and other testing.
• @t-lo for pointing out a compatability issue with 3Dmigoto and the Steam overlay.
• A bunch of other forum punks for confirming my observations and testing my fixes, many of which can be found in my earlier thread here.
• Some people I probably unwittingly ripped-off ideas from in my synthesis of information.

Feel free to comment with observations or corrections.

 

[Morbad]

File contents, for reference:

Spoiler: d3dx.ini

[Rendering]
shader_hash = 3dmigoto
assemble_signature_comments = 1
disassemble_undecipherable_custom_data = 1
patch_assembly_cb_offsets = 1
[Hunting]
hunting=0
[ShaderOverride-cdec4a73fdecbea7]
Hash=cdec4a73fdecbea7
Handling=skip

Spoiler: dxvk.conf

dxgi.customVendorId = 1002
d3d11.samplerAnisotropy = 16
d3d11.relaxedBarriers = True
dxgi.tearFree = False
dxgi.numBackBuffers = 2
dxgi.emulateUMA = True
d3d11.samplerLodBias = -0.5
dxgi.maxFrameLatency = 2

Changelog:

September 1st, 2022 - Have replaced the above d3dx.ini, both in the OP and here, with a minimalistic version that can correctly exclude the problem shader. The default can always be extracted from the original 3Dmigoto archive for those interested in shader hunting or more advanced features.

September 3rd, 2022 - Added spoiler tags to the workaround sections to mitigate clutter and clarified notes on EDHM compatibility.

September 28th, 2022 - Added a vendor ID line to dxvk.conf for those who are modifying the contents of their PlanetShaders folder.

October 28th, 2022 - Updated OP to reflect partial fix included in the 22.10.3 drivers.

 

[Mrc_NorthEast]

Thx for all the work and the write up @Morbad!

 

[Sunyavadin]

Honestly, this post ought to be pinned.

 

[TomCatT]

Didn't work. I will try again here in a bit.

 

[Morbad]

Didn't work.

What, specifically, didn't work?

Edit: Are you referring to the tint on planet surfaces you mentioned here? Using 3Dmigoto to disable the offending shader should definitely address that. Is VR still working and the tint/overlay still present? Did VR break? Did something else happen?

My WMR headset doesn't work on my main test system, so I'm limited in my ability to address VR specific issues without feedback.

 

[Balvald]

Also for workaround #2:

If EDHM is properly installed for Odyssey (it changes hud and menu colours and all that jazz) (easiest way is to use EDHM_UI: github.com/BlueMystical/EDHM_UI/releases/latest)

Then you can skip the steps in workaraound #2 concerning downloading and installing 3dmigoto and just put the lines for the shader bypass into the d3dx.ini that got installed with EDHM and then continue with the step where you need to modify the AppConfig.xml by setting "PermitNativeDoubles="false"".

Pro about that one is we can keep the custom EDHM colours that anyone that uses that mod has grown accustomed to while on newer drivers, and the num block doesn't get overtaken by the 3d migoto shader skipping controls that I used to find which shader was the culprit.

 

[Morbad]

Pro about that one is we can keep the custom EDHM colours that anyone that uses that mod has grown accustomed to while on newer drivers, and the num block doesn't get overtaken by the 3d migoto shader skipping controls that I used to find which shader was the culprit.

I don't use EDHM or the like, so this hadn't occurred to me. I'll update my post with a note to use this method if one is using EDHM.

As for the 3DMigoto hotkeys, I'm down to about six lines total in my modified d3dx.ini, which disables hunting and pretty much everything not related to just knocking out the offending shader. I'll add that to the OP soon for the default workaround.

 

[TomCatT]

What, specifically, didn't work?

Edit: Are you referring to the tint on planet surfaces you mentioned here? Using 3Dmigoto to disable the offending shader should definitely address that. Is VR still working and the tint/overlay still present? Did VR break? Did something else happen?

My WMR headset doesn't work on my main test system, so I'm limited in my ability to address VR specific issues without feedback.

VR is working just fine. It's like I never tried to install your files. The planet I'm parked next to looks worse. Do I need to use that loader file you have here first?

 

[Morbad]

VR is working just fine. It's like I never tried to install your files. The planet I'm parked next to looks worse. Do I need to use that loader file you have here first?

You need three files, two extracted from the 3Dmigoto archive, and the first file in my OP, renamed to remove the .txt.

 

[TomCatT]

You got to be kidding me. VR has a shader setup it uses. Non-VR WORKS great! I can see the planet just fine. How the hell do I tell ED NOT to recompile the planet tech when I use VR? I tried write-protecting the GpuWorkTable.xml, and it didn't work. Where is this data stored, or is it cached in memory?

 

[Morbad]

Can anyone else using VR confirm the issue TomCatT is encountering?

You got to be kidding me. VR has a shader setup it uses. Non-VR WORKS great! I can see the planet just fine. How the hell do I tell ED NOT to recompile the planet tech when I use VR? I tried write-protecting the GpuWorkTable.xml, and it didn't work. Where is this data stored, or is it cached in memory?

It would appear that VR either uses a different shader hash, or an additional problematic shader, than what is used otherwise.

Stopping shader warming/timing/generation almost certainly won't help. I've toyed with that idea significantly when trying to prevent the an incorrect terrain color/velveting issue in earlier version of the game/drivers; with no success.

Can you get a screen shot of what you're seeing? Or possibly run 3Dmigoto in hunting mode yourself and isolate the problematic hash?

 

[Balvald]

Can anyone else using VR confirm the issue TomCatT is encountering?



It would appear that VR either uses a different shader hash, or an additional problematic shader, than what is used otherwise.

Stopping shader warming/timing/generation almost certainly won't help. I've toyed with that idea significantly when trying to prevent the an incorrect terrain color/velveting issue in earlier version of the game/drivers; with no success.

Can you get a screen shot of what you're seeing? Or possibly run 3Dmigoto in hunting mode yourself and isolate the problematic hash?

Tested my current install that uses EDHM with my WMR headset. Seemed like I could reproduce it.

The thin atmosphere planet I went to in VR was missing a bit. Was hard to see at first but saw that a feint bit of texture just stopped in a straight line. Planet was Belalans A 4 at the time the affected area was on the dark side (so was hard to see).
In exploration mode the planet showed me the proper coloured map for exobiology signals even on the part that was missing the ground texture at that time.
Getting close to it distance dropped to 92m to surface and then jumps up to 2.6 Mm when flying over the missing part. So it definitly was missing something.

Also quite interesting to ram into the ground when the ship says it is 2.6 Mm far away.

I'd say I'm pretty much certain that its not because of a different shader hash. As the effect is still the same with approaching the thin atmosphere planet and not seeing the blue tint circle form.

Seems like its exactly this for VR. In which case I'd assume that it has this problem because we set "PermitNativeDoubles="false"

Under 22.7.1, and with that switch turned off, I can now do this...

Weird thing is that when I set "PermitNativeDoubles="true"" with the shader skip still on it did look like the planets tomcatT had in the post I quoted above.
Guess I was able to reproduce whatever happened in VR with "PermitNativeDoubles="true"" back then still happens in VR on 22.8.2?
Went to try to land on it regardless to get the expected Orange sidewinder.

After that I set "PermitNativeDoubles="false"" again. Restarted the game in VR being pretty close to Belalans A 4 but this time it wasn't missing the texture like before.
Checked the dark part vie the view shown on my mixed reality-portal because it shows whatever the vr headset can see with a higher brightness it seems.
Was able to check that way that Belalans A4 was not missing any texture or terrain this time.

Then I went to Bletones 2 A and was unable to find anything similar. All the planets I then went to were fine.

Quite the odd experience really that I just had.

What I havent checked just yet is, VR without the shader skip of mine. to see if it does anything different.

Edit: nope. everythings still fine with blue tint shader skip on or off. Difference is only whether or not I see blue tint on the thin atmosphere planets. all with vr.

Edit 2: Would've surprised me if it were otherwise I'd have probably noticed that EDHM wouldn't always perfectly work when I used VR and the chance would be high that hud or ui colours would be borked if the shader hashes were different in VR or so I'd think.

 

[Morbad]

Are either of you able to induce the error again after clearing the shader cache and deleting GPUWorkTable.xml?

There have been strangely intermittent issues related to terrain regeneration before, but they were less severe. Interestingly enough, the last time I saw that problem was before the new driver branch.

I'll head to one of these worlds later and see if I can get this to occur in 2D. Trying to discern if these are one-off errors, intermittent errors, or consistently reproducible.

Edit: @Balvald and @TomCatT if you find this issue to be repeatable can you try also disabling FMA (PermitFmaOptimizations="false") in AppConfig.xml and if that does nothing, see if replacing "\elite-dangerous-odyssey-64\PlanetShaders\TerrainComputeShaders.csa" by renaming TerrainComputeShadersNvidia.csa has any effect?

 

[Balvald]

Are either of you able to induce the error again after clearing the shader cache and deleting GPUWorkTable.xml?

There have been strangely intermittent issues related to terrain regeneration before, but they were less severe. Interestingly enough, the last time I saw that problem was before the new driver branch.

Emptied shader cache and deleted gpuworktable. Then did the first start that in VR mode Belalans A4 still all in one piece as is bletones 2 a for me and can land on them fine.

(Though the gpuworktable.xml was smaller then by about 3kb than the one that I had problems with. So it might be connected with the gpuworktable)
EDIT 1: size does not matter this time where I've broken it its the same size than the last time. maybe the bigger one was the slightly fixed version.

Then went to try get the initial condition back. by clearing shader cache und deleted gpuworktable then starting the game in 2D mode. Then switching to VR later to try to create the initial condition I had where bits of planets were gone. (With starting in vr mode being the only change that happened. meaining that happened from my fixed 2d state to vr and it having missing planet parts.)

And Bam! that did it.

First playing it in non vr mode and have it generate the gpuworktable then closing the game and restarting it in vr mode does it.

Gyazo

gyazo.com

I've never been so happy to have intentionally broken the game.

EDIT2: not fully confirmed yet but my experience from this would mean that'd should work by removing the gpuworktable and starting it in vr first I guess?

Will keep my game borked during the night and I will try the remaining permutations of fma on/off and terrainshaderreplacement tomorrow.
Then maybe also confirming that removing the gpuworktable and starting it in vr first works.

 

[Balvald]

Excuse the double post.

Was very easy to see if terrain generation was broken at bletones 2 a for me affected area has been in the light the whole time I tested.

Spoiler

I went through all permutations of fma on/off and terrainshaderreplacement in the borked state. changes nothing.
Only difference there is when replacing the terrainshaders, it loads a little longer at the planetary generation phase before the main menu because its recalculating something from anew because the shader changed. which is totally expected. It just doesn't take as long as generating a completely new gpuworktable from scratch.

I then just removed the gpu worktable and started the generation of the new one in steam vr mode and it's still borked.
Then I forgot that I didn't clear the shader chache. clear both started in vr first. no change still borked.

Then I did clear shader cache again and deleted gpuworktable. but had permitnativedoubles set to true (to try to retrace back the steps that seemed to fix it for me the first time.)
Still borked on the first start in vr, went to get my orange sidewinder by trying to land.
set permitnativedoubles to false
Still borked on the first start in vr, went to get my orange sidewinder by trying to land.

Full steps I took to fix it.

Spoiler

Tried to again recreate the situation I had in the first post to the letter.
start in nonvr first (fixes and everything as decribed in my edhm method, cleared shader cache and deleted gpuworktable before that start.)
planet is looking fine in non vr.
Went to vr to see the state of my initial post. it didn't look like the first problem just like a texture is missing for a quarter of the planet.

Gyazo

gyazo.com

set permitnativedoubles="true" restart in vr. and get the orange sidewinder
set permitnativedoubles="false" restart in vr. still borked went to try to land.
hmmm... still no change probably all useless what I did before? the steps that I tried for 3 slight different vairiation seem useless.

went close to the surface near bugged area. logged out close to the surface

Gyazo

gyazo.com

deleted gpuworktable (no shader cache cleaning.)
restarted in vr
I see terrain where there was none before!

Gyazo

gyazo.com

Then was unable to find any problems with bletones 2 a or any other landable planet thin atmosphere or not.

@TomCatT would be nice if you'd try the steps below. To see if it fixes it for you aswell.
Fix for vr should be:

1. with the workaround in place start vr and see that the planet are borked (if its not borked or you're not playing in vr anyway, you're fine go play)
2. try to land or get as close as possible to borked area in vr (just bonk it gently at 2.4Mm or whatever your equivalent may be so that the shield got taken down a notch to be really sure. but its probably enough to properly finishing the glide phase)
3. log out just a few meters before surface (best close everything part of elite dangerous)
4. delete gpuworktable.xml
5. restart in vr.
6. Planet surface should have reappeared.

Again some steps from this list might be not important, but best to just retrace these steps. steps that I omitted from my full steps in the spoiler above didn't seem to change anything.

Edit added some screenshots in the full steps spoilers showing the state of bletones 2 a at certain steps.

 

[Morbad]

Restored the files in the OP to their original ordering and updated d3dx.ini again to remove further redundant lines.

 

[TomCatT]

It sounds like some cache cleaning needs to take place. I don't think I've ever touched it in months. I'll keep you posted on my findings.

NOTE:
I can land, I have bad-looking colors, but I can walk around without falling into a pit of nothingness.

 

[CMDRKrite]

Hi, new here but not to the game... I came specifically looking for info on the 6000 series problem. I'm not particularly computer savvy so I'm not even going to attempt this workaround ... Good luck to those of you who are giving it a go. Instead, can I ask, has anyone heard anything about any impending patches and/or a rough idea of when we might expect one?

 

[Morbad]

I can land, I have bad-looking colors, but I can walk around without falling into a pit of nothingness.

This is exactly what 2D looks like without the shader workaround. Probably needs a different hash for VR. You should take a look at the 3Dmigoto documentation, enable hunting, and find which shaders your setup needs to bypass by on-foot content.

Hi, new here but not to the game... I came specifically looking for info on the 6000 series problem. I'm not particularly computer savvy so I'm not even going to attempt this workaround ... Good luck to those of you who are giving it a go. Instead, can I ask, has anyone heard anything about any impending patches and/or a rough idea of when we might expect one?

Frontier is aware of the issue, but have not announced a fix. AMD might be aware of the issue, but have not announced a fix. A patch for this issue might come next game or driver version, or never.

For non-VR setups, Workaround #2 involves editing a single variable in a text file and putting three files in the game directory. If you figured out how to install the game, this should not be difficult.