Anyone with an RX 6000 series card able to get Odyssey to run with the 22.5.2 drivers?

Testing now

Lol, nah.

20220822212847_1.jpg
 
Last edited:
Hello,

I can confirm that the dxvk solves the orange sidewinder error in both horizon and odyssey on a 6600xt with the 22.8.2 driver.

Calculation of shaders took waaay longer than usual but thats ok.

I run the game in borderless however its on top of everything. Using the windows key doesnt work, alt+tab causes a strange black screen for about ~0.3 seconds. In fullscreen the windows key works.

Going to supercruise or dropping from it on planets in seamless, opposed to whats its like without the fix (minifreeze).

Orbit lines are better but still a crime.

Havent tried stations yet.
 
The workarounds might be okish for ED, but AMD drivers newer than 22.5.1 still break other games too. E.g. DayZ just crashes trying to launch on anything other than 22.5.1, so as much as I'd like to update the drivers and try out the workarounds for ED, it still wouldn't help with other issues. :(
 
Well, I figured out my station specific issue...it was my own custom shadow profiles (specifically general and stationinterior), which haven't been an issue elsewhere. Certain stations do not tolerate non-EVSM shadows on AMD hardware.
 
Well, I figured out my station specific issue...it was my own custom shadow profiles (specifically general and stationinterior), which haven't been an issue elsewhere. Certain stations do not tolerate non-EVSM shadows on AMD hardware.
Was this under Linux or windows?
 
Current dxvk.conf settings I'm using:
Code:
dxvk.numCompilerThreads = 8
d3d11.samplerLodBias = -0.5
d3d11.samplerAnisotropy = 16
d3d11.relaxedBarriers = True
dxgi.tearFree = False
dxgi.emulateUMA = True

"dxvk.numCompilerThreads" feels like it works best equal to the number of physical cores, rather than the default, which is equal to the number of logical cores, but that setting is very optional.

"d3d11.samplerAnisotropy" is also entirely optional, and costs some performance, but the game clearly isn't applying 16x AF everywhere it should, even with that setting in the game options.

Was this under Linux or windows?

Windows.
 
"d3d11.samplerAnisotropy" is also entirely optional, and costs some performance, but the game clearly isn't applying 16x AF everywhere it should, even with that setting in the game options.
I felt like the game wasn't using AF properly, even after they added it to the graphical settings.

When I used an NVIDIA graphics card I would force 16x in the control panel; having switched to AMD and looking in the Adrenaline settings I was pretty annoyed to find their AF setting only works in OpenGL games...
 
When I used an NVIDIA graphics card I would force 16x in the control panel; having switched to AMD and looking in the Adrenaline settings I was pretty annoyed to find their AF setting only works in OpenGL games...

I'm pretty sure the description of that setting is incorrect. Setting AF or texture quality in the AMD drivers does seem to apply them most D3D applications, in my experience, all the way through DX12.
 
Current dxvk.conf settings I'm using:
Code:
dxvk.numCompilerThreads = 8
d3d11.samplerLodBias = -0.5
d3d11.samplerAnisotropy = 16
d3d11.relaxedBarriers = True
dxgi.tearFree = False
dxgi.emulateUMA = True

"dxvk.numCompilerThreads" feels like it works best equal to the number of physical cores, rather than the default, which is equal to the number of logical cores, but that setting is very optional.

"d3d11.samplerAnisotropy" is also entirely optional, and costs some performance, but the game clearly isn't applying 16x AF everywhere it should, even with that setting in the game options.



Windows.
Thank you. Much better inside carrier / station with those settings. Using Linux, Nvidia + Intel on laptop.
What I can see immediately - textures are loaded fast instead showing up around. I guess "dxgi.emulateUMA" was essential.
 
Last edited:
What I can see immediately - textures are loaded fast instead showing up around. I guess "dxgi.emulateUMA" was essential.

It seems to help every GPU I've tested with Odyssey and DXVK to some degree. Probably essential for low VRAM parts, but even my 16GiB Navi21 cards see fewer loading stutters around settlements with it.

tearFree enabled also tends to cause issues as it forces mailbox present mode when immediate is almost always better.
 
It seems to help every GPU I've tested with Odyssey and DXVK to some degree. Probably essential for low VRAM parts, but even my 16GiB Navi21 cards see fewer loading stutters around settlements with it.

tearFree enabled also tends to cause issues as it forces mailbox present mode when immediate is almost always better.
Make some sticky topic for this ;)
 
Makes me think of skipping out on 6**** series and wait for what's next from AMD.
Which may be just as problematic!
 
Restored conservative back buffer and frame latency limits to my dxvk.conf as I felt three full frames of latency in GPU limited scenarios was rather excessive.

What I currently recommend for optimal stability, latency, and IQ:
Code:
d3d11.samplerAnisotropy = 16
d3d11.relaxedBarriers = True
dxgi.tearFree = False
dxgi.numBackBuffers = 2
dxgi.emulateUMA = True
d3d11.samplerLodBias = -0.5
dxgi.maxFrameLatency = 2

The 'samplerAnisotropy' setting can be dumped for better performance, but the 'tearFree', 'emulateUMA', and 'samplerLodBias' settings should be considered mandatory as they prevent some crashes and can smooth out performance considerably.
 
Got my own Hotfix for the blueish annoyance around planets with thin atmospheres.

With the previous PermitNativeDoubles="false" I went shader hunting with 3dmigoto and found the culprit.
Well I have no idea how the shader is called or what its specific purpose is. Only that is has to do with the thin atmosphere planets, and that the shader leaves a space thats not blue around whats the horizon of that planet and the hash so I could tell 3dmigoto and by extension my EDMH installation to just skip that shader until a fix arrives.

Now I just added

Code:
[ShaderOverride-cdec4a73fdecbea7]
hash = cdec4a73fdecbea7
Handling = skip

to the d3dx.ini of my EDHM install.
This just skips the shader that goes blue when PermitNativeDoubles="false"
Thats is 6700XT on newest optional drivers playing ED:Odyssey version 4.0.0.1400

For Horizons (is it even a problem there?)
If it were it probably has another hash value representing that shader.

Edit: Also I suspect it'll only hold until the next update as those hashes probably change not too rarely.
 
why going to the extent of all these troubles to use "optional" drivers instead of sticking with the last official whql version?
which, surprisingly or not, is the 22.5.1 which are not crashing on EDO planets.
 
Back
Top Bottom