Dxvk: Elite Dangerous 3.3 Volumetric Effects/fog performance issues

[fls2018]

Game runs fine however one particular graphical setting (Volumetric Effects Quality) has severe performance degradation compared to Windows, often seeing a third of the expected performance whereas Windows experiences very little performance loss setting this between High & Ultra. Other settings have expected performance for DXVK vs Windows.

Volumetric Effects was recently updated in version 3.3 of the game to include things like fog in ring systems and smoke effects at stations.

Here's an example of performance in Windows, note it sits around 100 fps:

https://www.youtube.com/watch?v=xRxbQenhLt4

And here's it with DXVK in Wine 4.2 Staging same settings as Windows, bouncing between 30-40 fps:

https://www.youtube.com/watch?v=qQAZSuJlWxQ

This is a GPU bound issue, my CPU scaling Governor is set to performance and nvidia-smi shows the GPU pegged and all clocks as expected.

Software information

Elite Dangerous Horizons, setting affected is Volumetric Effects Quality on Ultra.

On an extra note here's a snip from the the games GraphicsConfiguration.xml, it appears that the DownscalingFactor whatever that adjusts is the root cause:

<Ultra> <LocalisationName>$QUALITY_ULTRA;</LocalisationName> <StepsPerPixel>24</StepsPerPixel> <DownscalingFactor>1</DownscalingFactor> <BlurSamples>4</BlurSamples> <TwoPassBlur>true</TwoPassBlur> <InScatterSteps>2</InScatterSteps> <StepMultiplier>6.0</StepMultiplier> <RingQuality>3</RingQuality> <FogMotesEnabled>true</FogMotesEnabled> </Ultra> </Volumetrics>

System information

• GPU: GTX 1070
• Driver: 418.31.03
• Wine version: 4.2 Staging & Custom patched Proton by RedMcG
• DXVK version: Master & release 0.96 (but same issue on older versions).

Apitrace file(s)

Link (2.5GB): https://drive.google.com/file/d/19xS5pSpz0StlTOSvcA9yw6NC1myJFJBh/view

Not sure if it's got all the info as it was around 5 fps while recording the apitrace, unsure whether the initial shader load was carried out due to that but hope there's enough info on what the likely issue is.

Log files

• d3d11.log:
  EliteDangerous64_d3d11.log

• dxgi.log:
  EliteDangerous64_dxgi.log

[doitsujin]

Seriously, what's with all the performance complaints as of late?

Anyway, I can't look into this without an apitrace, youtube videos don't really help. It's also very unlikely that this can be improved in DXVK since volumetric effects like this are usually just implemented as a single, long-running shader.

As for apitrace, you can use it with DXVK in this case since the game clearly workss (doesn't crash, renders fine).

[fls2018]

Apitrace and logs added.

Seriously, what's with all the performance complaints as of late?

It's not a recent issue or regression with dxvk as such, I did want to report this when ED update 3.3 launched in December but I was waiting around for the recent Nvidia driver fix for a separate corruption issue (that affected windows as well) before focusing on mentioning this.

Anyway I fully understand things take time and in no way expecting you to immediately fix stuff, however I'm hoping you can look at this and give some insight on whether this sort of thing is likely to improve over time either with dxvk or optimizations elsewhere (drivers etc).

Other than this one setting the game runs brilliantly, really impressed with the progress of dxvk so far thanks again.

[doitsujin]

Thanks for attaching the apitrace.

Ironically I'm getting better performance when replaying your apitrace on my AMD card that you seem to get during gameplay, and I don't see high GPU load either, so it's likely that the Nvidia driver fails to optimize the volumetric lighting shader properly. My Nvidia test system is currently out of order due to a broken hard drive, so I can't test it there right now.

Looking at the particular shader, I'm not even surprised though. Frontier clearly wrote inefficient code, Microsoft's HLSL compiler for some reason also failed to optimize a simple constant array to an "immediate constant buffer" as they call it, and now we have a shader that initializes a fairly large constant array in every single invocation, just to read one value from it. I wouldn't be surprised if that's the issue here. DXVK doesn't optimize that (as it doesn't do any code transformations besides a naive dxbc->spirv translation), so the driver has to deal with this mess.

[fls2018]

Thanks for looking at it, I'm guessing it's not the case of something unimplemented in dxvk and more the messy code being a bottleneck?

It's strange though on Windows this setting barely makes a dent to performance, where it's literally around 5% difference between low & ultra.

[jp7677]

@fls2018 Note that the shader the driver has to process is not the same between running ED on Windows and Linux. On Windows the Nvidia driver gets the DX shader code and on DXVK it is Vulkan/SPIRV shader code that has been generated from the DX shader code. My understanding is that the driver contains separate shader compilers for DX and SPIRV, with probably lots of differences and different optimizations. Having inefficient code to begin with certainly doesn't help when the shader needs to go though (general) transformation first before it goes into a relatively young shader compiler in the driver.

Ironically the compiler for AMD cards seems to handle this better (based on @doitsujin words, I don't have an AMD card) considering that DXVK spoofs an NVidia card for ED to get the game even started on AMD cards :)

PS: I'm no expert in this area, so please take my words with care.

[fls2018]

@doitsujin
I do have another issue thought I'd keep it to this thread. I'm getting red squares in certain situations, something to do with lighting.

Edit: This ones related to the bloom setting, setting it from ultra to high makes the artifacting go away.

It's happening in this video at 15 seconds:

https://youtu.be/DSV0a7lbH2M

It's hard to replicate, also when I tried to make an apitrace it didn't render the laser and had different glitches. I'm currently uploading it anyway although don't know if it's much use.

Apitrace: https://drive.google.com/file/d/1BVZlu1mLEPw-Jm8n9PpBdhHF5zpZllmL/view

[fls2018]

Small update on this, I've tried using DXVK on Windows 10 and both issues above still occur.

Here's a video: https://www.youtube.com/watch?v=G6K9_cHcr6Y

At around 0:20 I switch Volumetric effects on Ultra and lose around 30-40 fps. Not quite as heavy hitting as on linux but a massive deficit vs standard windows dx11 for one setting that virtually has no performance deficit with dx11.

Also at 1:25 you can see the bloom related square glitch I mentioned above appear, switching bloom from Ultra to high makes it go away.

I don't know whether it's Nvidia drivers or DXVK causing these issues but it's definitely Vulkan related.

[sjnewbury]

This seems to be working well for other people, but for me, while performance is good, the colours are very wrong. It looks like the wrong buffer format. Indeed in the log I get a warning about "DXGI: VK_FORMAT_D24_UNORM_S8_UINT -> VK_FORMAT_D32_SFLOAT_S8_UINT",

I'm using RADV, which indeed doesn't support VK_FORMAT_D24_UNORM_S8_UINT, unfortunately. Perhaps this is a Red Herring, since presumably the format should be remapped, but it's the only clue I can find as to what's going wrong, and why at least for NVidia users there aren't any apparent issues.

This occurs running under any proton version I've tried and with custom build updated to the latest DXVK. I've been unable to test running under regular wine since for recent purchasers of ED, Frontier no longer allows Steam users to login through the launcher without purchasing a license directly from Frontier. However, as an additional data point the demo version works fine with wine-staging, but as I understand that is much much older code.

Update:
I tried partially reverting the support for remapping VK_FORMAT_D24_UNORM_S8_UINT -> VK_FORMAT_D32_SFLOAT_S8_UINT in DVVK and it behaves exactly the same, so I guess it was a Red Herring. I'm now pretty convinced it's a problem with a shader, in particular the ambient lighting and colouration, It appears inverted.

Update2:
This seems to be a Mesa bug. I'm currently bisecting it. It's taking a while...

[sjnewbury]

@doitsujin
I bisected the problem to the conversion of NIR to 1-bit booleans (https://gitlab.freedesktop.org/mesa/mesa/commit/3b3081479163475f25b908008250d83c31716c34). Previously NIR boolean types match d3d10 booleans, so no conversion was necessary. Presumably the code emitted by DXVK doesn't have to take this into account since I would assume it would be driver internal, but maybe not? I left a comment on the commit in the mesa repo.

[doitsujin]

@sjnewbury thanks for doing the bisect; this does indeed sound like a Mesa bug then. SPIR-V bools are strongly typed so there's pretty much nothing that DXVK could be screwing up on that front.

[sjnewbury]

https://bugs.freedesktop.org/show_bug.cgi?id=111141
@doitsujin I've opened the above bug on the Mesa Bugzilla on request of Jason Ekstrand. Now I just need to figure out how to identify and extract the broken shader either side of the commit. Perhaps you can help me with that, it's an area I've no real experience in, but I'm a competent coder so I should be able to get there! :-)

[doitsujin]

The easiest thing would be to just upload a RenderDoc capture of a broken frame somewhere and post it on the bug report.

[fls2018]

@sjnewbury

Considering you have an AMD card I'm wondering if you can help confirm my original performance issue only exists on Nvidia? To do this you need to test in specific locations in the game where volumetric effects are leveraged more, only certain stations/ring systems/stella phenomena really leverage it.

Iben Hub station in the Iota Hydri system is a good candidate, you'll need to do some jumping from your current location in Asellus Primus so you'll need to upgrade your jump range & maybe add a fuel scoop if you don't want to stop at stations on the way (it's 141 ly away).

What you should be looking for with Volumetric Effects on Ultra is a severe performance drop vs what you'd get normally at a station. If you get similar performance in Iben Hub to elsewhere then my issue exists only for Nvidia.

[sjnewbury]

@sjnewbury

Considering you have an AMD card I'm wondering if you can help confirm my original performance issue only exists on Nvidia? To do this you need to test in specific locations in the game where volumetric effects are leveraged more, only certain stations/ring systems/stella phenomena really leverage it.

Iben Hub station in the Iota Hydri system is a good candidate, you'll need to do some jumping from your current location in Asellus Primus so you'll need to upgrade your jump range & maybe add a fuel scoop if you don't want to stop at stations on the way (it's 141 ly away).

What you should be looking for with Volumetric Effects on Ultra is a severe performance drop vs what you'd get normally at a station. If you get similar performance in Iben Hub to elsewhere then my issue exists only for Nvidia.

I will do that once I've resolved my bug, since it's a brand new account it will take a few hours of gameplay to get there. BTW, I'm not new to ED, I've played it for years on the PS4, just saw it in the Summer Sale on Steam and always wanted to play it in VR so I thought I'd try to help iron out the issues.

[sjnewbury]

@doitsujin I've built RenderDoc, but I can't figure out how I can attach it to the EliteDangerous64.exe. Should I be using the Windows version under Proton on the same pfx instead??

[doitsujin]

If you set up the Vulkan layer that comes with RenderDoc (running renderdoccmd will tell you how), export ENABLE_VULKAN_RENDERDOC_CAPTURE=1 and then start Steam.

[sjnewbury]

It's sort of almost working. The layer works but the resulting capture reports "File corrupted: Unrecognised section type 'xx'
xx varies
Oops! My tmp is full! I'll try again! :-$

[sjnewbury]

Hmm... It's refusing to use a different tmpdir and I only have 1G available in /tmp :-(

[sjnewbury]

I don't know why the temporary capture directory isn't changing, but anyway, I created a symlink to work around it. Where should I upload the captures, they're probably too big for the mesa bugzilla..?

[sjnewbury]

Looks like it's within the mesa bugzilla limit. Before commit capture is uploading.

[sjnewbury]

The upload of the broken rendering rdc file is complete, it's pretty big, over 700MB.

[sjnewbury]

@doitsujin I've updated the mesa bug with my understanding of the process, I wouldn't mind if you could take a look and point out anything I've got wrong with my thoughts, or whether you could make a educated guess where I/we should be looking.

[fls2018]

The secondary issue with bloom I reported in this thread (the coloured square corruptions) seems to have resolved itself. Don't know whether it was a recent driver, wine or dxvk that fixed it but I can no longer reproduce the issue.

The main issue still remains, I still haven't been able to get anyone to test volumetric effect performance on AMD in the same locations so a bit clueless whether to this is an Nvidia specific issue or something else.