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

Rat Catcher

Rat Catcher
Northpin said:
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.
Click to expand...
Probably because of the gains offered with many other DX11/ OpenGL titles?
 

Morbad

Morbad
Balvald said:
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.
Click to expand...

Very nice.

I was temped to do this myself, but figured the shader was doing something that would occasionally be meaningful as it's performance hit is fairly large (though who knows...the game seems riddled with settings that have negligible impact on IQ that still require an inordinate amount of processing), and DXVK actually appears to be slightly faster in CZs anyway.

And Horizons should work fine without needing any fixes.

Northpin said:
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.
Click to expand...

Because the newer drivers fix other bugs, are ~10% faster in most other D3D11 apps, and almost ~50% faster, on average, in OGL apps.

Also the DXVK workaround with the newer drivers is pretty stable, about the same performance in GPU limited scenes as 22.5.1 (or prior), and actually faster in CPU limited areas.
 
Last edited:

DIngBatDave

D
Northpin said:
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.
Click to expand...
People like tinkering with the setting. I totally get it. Making things work that don't. Helping others do it, passing knowledge etc etc. I don't personally do it. But I 100% understand why people do it. I think on the whole it's great.
 

Northpin

Northpin
Rat Catcher said:
Probably because of the gains offered with many other DX11/ OpenGL titles?
Click to expand...

Probably.jpg
 

Morbad

Morbad
Currently around eight consecutive hours into a session using 22.8.2 and the aforementioned DXVK settings.

No crashes or stability issues so far, and performance has generally been good. However, VRAM utilization has gradually worked it's way up to 11-12GiB and for the last hour or two I've been seeing reduced CPU and GPU utilization while in both normal space and supercruise. Everything is still smooth, but frame rate in these areas is about half of what it was during the first half of the session. Utilization and frame rate on foot has been unaffected.

I might try disabling UMA and manually setting reportedmemory sizes in DXVK, or I could just restart the client every four to six hours or so.

EDIT: Haha, performance degradation was due the old chat window tab bug that they still haven't fixed after, what, five years now? Anyway, I had something like 150+ systems built up in the system chat window that I have on another tab that I almost never check. Going to the chat menu and letting all these systems scroll restored me to full performance.
 
Last edited:

Morbad

Morbad
Tested disabling the shader @Balvald discovered with 3dmigoto and it does indeed fix the issue with the blue overlay on the 22.8.2 drivers (and presumably the others from the May preview drivers on). No change to performance (was hoping the shader that was revealed by the blue overlay had a performance impact associated with it), but no clearly discernible missing visual effects either.
 

TomCatT

TomCatT
Welp, I no longer receive Orange Sidewinders in VR. I was able to land on the disfigured planet. To me, the body now has pitfalls. Once in the atmosphere, even the sky has an off-green tent to it. Once below 109m, you'll see for sure, so watch that first step when you exit your vehicle. It looks like my other games play well with v22.8.2. Next test, I'm going to play with DXVK.
 

Morbad

Morbad
Last edited:

BlakeA

BlakeA
AMD driver 22.7 results in 100% chance to (game) crash on entering glide to de-orbit to planetary surface.
AMD driver 22.8 I played for 3 days no issue, the moment i entered glide: game crash.
 
Last edited:

Morbad

Morbad
People can use whatever drivers they like. I've got systems where I haven't updated the GPU drivers in years because there is little improvement to be had in anything they do.

That said, the newer AMD drivers do improve Odyssey performance, and if every last bit of performance matters, I recommend trying them with one of the workarounds mentioned in the pinned thread on the topic. Some people have issues, but I wouldn't go back, even if I didn't play any other games that benefited.
 

TomCatT

TomCatT
I'll try later.

UPDATE:
Non-VR works for 22.10.1 just fine.
In VR, no-go. The planet looks mangled again. So VR has its planet tech different from non-VR? I didn't think that was a thing.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom