AMD RX 6000 series driver issues & workarounds

GPUWorkTable.xml is in the same directory as the main game executable.

Shader cache reset is at the bottom of this page in the AMD control panel:
HPxwuNk.png
Thank you.
After applying the 3rd workaround with 22.10.3 I have no issues with Odyssey. But I never deleted the GPUWorkTable, nor did I clear the cache.
I will do it just to get a clean slate.

I also noticed that the 2 dxvk.conf files that you provided are slightly different - there are 2 more parameters in one of your earlier conf files:

dxgi.deferSurfaceCreation = True
d3d11.zeroWorkgroupMemory = True

and dxgi.maxFrameLatency was set to 1 instead of 2.

Is this something that can have an impact on overall performance or is it OK to use the one from the first post of this thread?
 
Thank you.
After applying the 3rd workaround with 22.10.3 I have no issues with Odyssey. But I never deleted the GPUWorkTable, nor did I clear the cache.
I will do it just to get a clean slate.

Unless you have a specific reason to use workaround #3, you should be using #2, as it's both faster and more compatible on most systems. Using DXVK might help some more CPU limited systems, however.

I also noticed that the 2 dxvk.conf files that you provided are slightly different - there are 2 more parameters in one of your earlier conf files:

dxgi.deferSurfaceCreation = True
d3d11.zeroWorkgroupMemory = True

and dxgi.maxFrameLatency was set to 1 instead of 2.

Is this something that can have an impact on overall performance or is it OK to use the one from the first post of this thread?

I updated the posts relating to dxvk.conf quite a while ago, as noted in post #2.

"deferSurfaceCreation" and "zeroWorkgroupMemory" should not be needed or have any impact, but I haven't exhaustively tested every setting.

:maxFrameLatency" at "1" vs. "2" very likely slightly reduces performance, but also reduces input latency. The game doesn't have severe latency issues, but does tend to have major CPU/memory bottlenecks, so most people, if they can even tell the difference, would probably prefer "2".
 
Unless you have a specific reason to use workaround #3, you should be using #2, as it's both faster and more compatible on most systems. Using DXVK might help some more CPU limited systems, however.



I updated the posts relating to dxvk.conf quite a while ago, as noted in post #2.

"deferSurfaceCreation" and "zeroWorkgroupMemory" should not be needed or have any impact, but I haven't exhaustively tested every setting.

:maxFrameLatency" at "1" vs. "2" very likely slightly reduces performance, but also reduces input latency. The game doesn't have severe latency issues, but does tend to have major CPU/memory bottlenecks, so most people, if they can even tell the difference, would probably prefer "2".
Thank you.
I am happy to take a good advice so I will give #2 a try.
 
Unless you have a specific reason to use workaround #3, you should be using #2, as it's both faster and more compatible on most systems.
I am now using workaround #2 (reverting to 22.5.1 messed up Resolve, for some reason!) without any issue.

Quite sincerely, thank you for sharing your knowledge!

I'd intended to sit around and wait for AMD / Frontier to offer a fix, but am happy that I didn't.
 
I play using the Steam version of Odyssey, using the AMD 22.10.3 drivers - am I right in thinking that workaround #2 doesn't work with the Steam version? I've followed the steps set out by Morbad (thank you, by the way!) in workaround #2, but I'm still getting the teal (dis)coloration on atmospheric planet surfaces, so I'm guessing the offending shader is still at work. Does anyone know of any potential solutions for Steam users ?
 
Last edited:
I play using the Steam version of Odyssey, using the AMD 22.10.3 drivers - am I right in thinking that workaround #2 doesn't work with the Steam version? I've followed the steps set out by Morbad (thank you, by the way!) in workaround #2, but I'm still getting the teal (dis)coloration on atmospheric planet surfaces, so I'm guessing the offending shader is still at work. Does anyone know of any potential solutions for Steam users ?

I don't use Steam, but I'm not sure why it would be incompatible, unless you're not placing the 3DMigoto files in the right directory, or Steam is automatically cleaning that directory.
 
I'd say you should send support requests (not the issue tracker) with this issue (22.10.3 drivers and the shader issue)

Unless the ball is still in AMD's backyard, maybe FDev can fix that shader in time for U14... else U15? U16?
 
I don't use Steam, but I'm not sure why it would be incompatible, unless you're not placing the 3DMigoto files in the right directory, or Steam is automatically cleaning that directory.
I'll give it another go and report back - hopefully it's just a matter of me having fluffed a step in the process
 
I don't use Steam, but I'm not sure why it would be incompatible, unless you're not placing the 3DMigoto files in the right directory, or Steam is automatically cleaning that directory.
Alas, I'm still not having any luck. I might be doing something wrong, but here's where I am at present. In the game directory that contains EliteDangerous64.exe, I have the following files as per workaround #2: d3d11.dll (x64), d3dcompiler_46.dll (x64) and d3dx.ini

The only clue I have as to what might be wrong is the error message I get in the top left hand corner of the screen when loading up the game: Error opening D:\SteamLibrary\steamapps\common\Elite Dangerous\Products\elite-dangerous-odyssey-64\d3dx.ini

I'd be curious to know if other Steam users have encountered this
 
The only clue I have as to what might be wrong is the error message I get in the top left hand corner of the screen when loading up the game: Error opening D:\SteamLibrary\steamapps\common\Elite Dangerous\Products\elite-dangerous-odyssey-64\d3dx.ini

Well that explains why it's not working, as without the contents of the ini file, 3DMigoto cannot know what shader to disable.

The remaining question is why the ini can't be loaded...I'd check file permissions and security settings.
 
Well that explains why it's not working, as without the contents of the ini file, 3DMigoto cannot know what shader to disable.

The remaining question is why the ini can't be loaded...I'd check file permissions and security settings.
I couldn't get it to work in the normal fashion, so I ended up going the EDHM route, adding the "[ShaderOverride-cdec4a73fdecbea7] | hash = cdec4a73fdecbea7 | Handling = skip" lines to the d3dx file, and now I'm back to teal-free planetary exploration. Thanks for everyone's input!
 
I'm still at stable driver 22.5.1 with RX 6800 XT which works really well for me, is it worth to upgrade to the latest beta 22.10.3?
 
I am with the latest AMD drivers, and the game does not crash on the planets but I have the green color problem on the scanned planets.
I'm not going to make any changes to the game files ...
It's not fair that I have to do it, the game developers or AMD have to think about it.

This thing from my point of view has been going on for too long now ...
 
It's not fair that I have to do it, the game developers or AMD have to think about it.
You could use the recommended driver instead, then you'd need to do nothing at all.

The optional drivers are just that, optional, not mandatory. If they have issues (which they do with ED etc.) then it is by choice keeping them installed.

I took the 2 minutes it needed to download and setup the mods as suggested by @Morbad so can benefit from other functionality introduced after 22.5.1, my choice.

Possibly AMD will make a greater effort to ensure maximum compatibility before 12th December, with the launch of RDNA 3 product, wait and see, essentially.
 
I'm still at stable driver 22.5.1 with RX 6800 XT which works really well for me, is it worth to upgrade to the latest beta 22.10.3?
Yes, if you need the DX11 boost, or the Noise reduction functionality. It only takes a couple of minutes to download and setup the fixes suggested, and, if they don't work for you, revert to 22.5.1 once more.
 
Yes, if you need the DX11 boost, or the Noise reduction functionality. It only takes a couple of minutes to download and setup the fixes suggested, and, if they don't work for you, revert to 22.5.1 once more.
I was about to say the same. There are some performance improvements with the optional drivers (alas with some tinkering).
 
I was about to say the same. There are some performance improvements with the optional drivers (alas with some tinkering).
I was reluctant to move from 22.5.1 to the new drivers, particularly as they needed a 'home-brew' fix to have EDO work normally. Following the topics here I decided it was worth looking into.

I should have done so much earlier, is my opinion.
 
I couldn't get it to work in the normal fashion, so I ended up going the EDHM route, adding the "[ShaderOverride-cdec4a73fdecbea7] | hash = cdec4a73fdecbea7 | Handling = skip" lines to the d3dx file, and now I'm back to teal-free planetary exploration. Thanks for everyone's input!

This is odd, since EDHM should be using 3DMigoto in a similar fashion...but whatever works.

It's not fair that I have to do it, the game developers or AMD have to think about it.

This thing from my point of view has been going on for too long now ...

Ideally, games and drivers would be bug free, while any comparability issues that did crop up would be addressed promptly and decisively.

However, the reality is that this is an eight-year-old niche title, bound to be low on both Frontier's and AMD's lists of priorities, that has problems with one generation of GPUs from a brand that hasn't sponsored the game.
 
Back
Top Bottom