[Feature Request] Option to change between DirectX 12 or Vulkan on Windows
vini1264 opened this issue · comments
I think it would be nice to have an option to choose either D3D12 or Vulkan on Windows. The recomp ran a lot better on my GTX 1060 when I changed the default api to Vulkan in graphics.json. So having the option change it in the graphics settings would be very convenient.
The recomp ran a lot better on my GTX 1060 when I changed the default api to Vulkan in graphics.json. So having the option change it in the graphics settings would be very convenient.
Does this happen on a stable scene after waiting a few minutes? I'm curious if perhaps you have a CPU with a low core count, so you're getting a bigger benefit out of Vulkan because it skips shader compilation by using specialization constants instead. What you might be experiencing is it takes longer for the optimized shaders to appear in one API versus the other one.
This is one reason a system with a low core count might prefer Vulkan, but there's a few reasons as to why it's not the default in Windows due to some integration issues (missing out on DXGI is a big one). But I'm curious if it'd be smarter to choose it based on the user's CPU. I have my doubts your GPU performs significantly better in either API on this case. Probably a waste of time as I do want to see if I can improve the situation in D3D12 by patching the DXIL instead if possible.
That said, I do agree with the idea of exposing an option as long as it's not front and center as it's largely irrelevant for most users and a setting that requires restarting the game.
The recomp ran a lot better on my GTX 1060 when I changed the default api to Vulkan in graphics.json. So having the option change it in the graphics settings would be very convenient.
Does this happen on a stable scene after waiting a few minutes? I'm curious if perhaps you have a CPU with a low core count, so you're getting a bigger benefit out of Vulkan because it skips shader compilation by using specialization constants instead. What you might be experiencing is it takes longer for the optimized shaders to appear in one API versus the other one.
This is one reason a system with a low core count might prefer Vulkan, but there's a few reasons as to why it's not the default in Windows due to some integration issues (missing out on DXGI is a big one). But I'm curious if it'd be smarter to choose it based on the user's CPU. I have my doubts your GPU performs significantly better in either API on this case.
That said, I do agree with the idea of exposing an option as long as it's not front and center as it's largely irrelevant for most people and a setting that requires restarting the game.
My CPU is an Intel Core i5 7400, but in my case the issue with D3D12 wasn't performance issues, but micro-stuttering / frame pacing issues. Every time I start the game there's a micro-stutter on my end, which stabilizes after some seconds of playing and it runs smoothly, the micro-stutter becomes more an issue for me when I use the lens of truth on a section that has invisible objects.
When I changed to Vulkan all the micro-stuttering I was having in D3D12 goes away and the game runs butter smooth.
which stabilizes after some seconds of playing
That's shader compilation. We don't keep a shader cache for the DXIL itself, but if your CPU isn't too fast I can see why it'd happen. But yes, this is not necessarily that Vulkan runs faster than D3D12, it's just that the shader specialization takes less time in your system and it's enough time in your system to be noticeable.
You can keep playing in Vulkan if it solves the issue for you, that's completely fine.
Some time ago I did some DX12 vs Vulkan performance tests in PCSX2 and other emulators and the truth is that the performance in Vulkan is superior by around 10 fps if I remember well... I also vote in favor of having an option to change the api ...
i7 9700 / GTX 1660Ti / 16Gb Ram / Windows 11
I think being able to change the API by setting it in graphics.json, which you can already do, is good enough, and I think having an easier to access option in the UI is a bad idea. I'd rather not add a way to do it in the UI because Vulkan drivers on Windows tend to have more bugs than D3D12 ones, so I don't want people accidentally changing the setting and then reporting bugs to this project or RT64. This may sound like a weird concern, but I've already watched people just mess around with the settings in recomp on streams without reading the descriptions, then ask questions like "why is there no option to render at high resolution" because they turned on downsampling.
In particular, graphics driver bugs usually trigger a large investigation on our end that takes up a lot of time that we'd otherwise be working on the project, and these would be completely avoidable bug reports for the most part. For a much more in-depth explanation about the many reasons why D3D12 is the default on Windows over Vulkan, check out this response here: N64Recomp/N64Recomp#63 (comment). The biggest issues of note are that screenshots while in fullscreen just don't work in Vulkan on Windows and Vulkan does not offer the same input latency reduction features that D3D12 does. Not listed there is also the fact that Vulkan drivers on Windows support fewer generations of old GPU hardware than D3D12.
Some time ago I did some DX12 vs Vulkan performance tests in PCSX2 and other emulators and the truth is that the performance in Vulkan is superior by around 10 fps if I remember well... I also vote in favor of having an option to change the api ...
i7 9700 / GTX 1660Ti / 16Gb Ram / Windows 11
Measurements done on one program are not relevant at all for other programs. I've collected a wide arrangement of hardware for testing RT64/recomp on during development, and on every test we've done in Windows D3D12 performs better than Vulkan once both environments have finished compiling optimized shaders in the background. The D3D12 shaders do take longer to compile currently, but that will be mitigated in the future and is only relevant on very slow CPUs. The way RT64 supports multiple APIs is different than how emulators tend to do it, in that it's one single rendering backend with a very thin abstraction layer on top of the API itself. This means that the way RT64 uses the two APIs is as similar as possible, so the comparison is very 1:1. Emulators on the other hand tend to have completely separate backends for each API, so their usage of the two APIs tends to be very different.
TLDR: You can already change it in graphics.json config file. Allowing changing it in the UI would make it very easy for users to accidentally run into driver bugs, as D3D12 drivers are in a much better state on Windows than Vulkan. A lot of hard-earned lessons on our part went into the reasoning behind picking D3D12 as the default on Windows.
I would suggest adding the setting an advanced tab in the options menu with a warning saying that users shouldn't change it unless they know what they're doing. But if you're still not willing to add it I'm not going to complain and bother you further, the reasons you gave for this decision are very fair, and like you said the option is always there in graphics.json if an advanced user wants to change the API if they want.
If we ever have an advanced options tab then I can consider putting it there, with a big warning like you said and a disclaimer that it won't take effect until after a restart. I did forget to mention that there are cases where switching API can cause programs to not start up (or just boot to a black screen as some users have encountered) if there's a particularly bad graphics driver bug or if their hardware supports one API and not the other, so explaining how to revert it would have to be in the warning as well.
Adding an advanced graphics option like this doesn't really serve to benefit the user in the end, unfortunately many people disregard warnings, and assume that if there is an option then its safe to toggle. I think we'd likely see many new issues pop up that the user switched the driver and can no longer boot, and we'd be back here explaining they can fix it by editing/resetting the json config by hand. The advanced option is safer and still accessible through the json config this way