RetroArch
RetroArch copied to clipboard
libretro
RETROARCH crashes with d3d11 and 12 from ver. 1.9.9 on.
I run Retroarch on a system powered by an i7 4790K, outputing 15 khz signal through a R9 380x with CRT Emudriver 2.0 installed. The machine runs Windows 10 ver. 1511, since it's the Win 10 build with the lowest input latency ever released. But things gone pretty bad when Retroarch started to crash with d3d11 and 12 drivers, from ver. 1.9.9 onward. Now we hit RA ver 1.10.3 and it still works only with d3d10 and OpenGL, both delivering lower performance in many cases. I suspect the changes made to the d3d11 and 12 drivers to accomodate/implement FSR features are causing these incompatibilities with certain systems on which RA worked perfectly before. Is there something I can do to fix this unexpected driver incompatibility, or I will be forced to upgrade my perfect and stable installation to say, 1903, in order to enjoy new BIG features as Automatic Frame Delay, despite the fact I don't care at all with FSR and the like? Thanks a lot.
FSR is unrelated. It's implemented as a shader and doesn't touch the actual drivers at all.
What would need to happen is figuring out when it actually broke so we can then determine how to fix it.
You need to provide way more information than this. Your system specs, your drivers, etc. Also a bisect would be nice.
I suspect it could be something to do with the HDR support that was added for the DX11 and DX12 drivers, but that still shouldn't crash things.
No crashing with either d3d11 or d3d12 for me. HDR is fine. Not using a CRT.
Tested versions: Stable 1.10.0, 1.10.1, 1.10.2, 1.10.3 Nightly build d7a30f2a18ad8cf689da94437440f438756e504d
Windows 11 Nvidia RTX 3090 latest driver (516.59 as of now) Intel i9 10900X
Hmm that custom R9 390x driver simply might have spotty/incomplete D3D11/D3D12 support. What D3D11 feature levels does it support?
Can you bisect what the last commit was that still worked for you on your particular setup? I don't have a system with a CRTEmudriver or compatible GPU so it'd be hard to reproduce.
No crashing with either d3d11 or d3d12 for me. HDR is fine. Not using a CRT.
Tested versions: Stable 1.10.0, 1.10.1, 1.10.2, 1.10.3 Nightly build d7a30f2
Windows 11 Nvidia RTX 3090 latest driver (516.59 as of now) Intel i9 10900X
Hi there. Yes, it runs perfectly from Win 1803 on, even with the CRT Emudriver! Unfortunatelly, Win 10 significantly increased in latency after the 1511 build. It's not related to video drivers or GPU brand. It's the Win 10 version and some implementation not present in earlier versions. Newer RA releases work perfectly on my other machine (i5 12600K / RTX 3080 10GB with Game Ready latest driver / Win 10 22H2).
Hmm that custom R9 390x driver simply might have spotty/incomplete D3D11/D3D12 support. What D3D11 feature levels does it support?
Hi there! Sorry for the delay. Ok. So I tested the same marvellous CRT Emudriver 2.0 with the same R9 380X GPU, but this time with Win 10 1803 build. The result was that both D3D11 and 12 worked normally, but with a taste of lost war! I read HDR was implemented in W10 from this 1803 build on. While the W10 1511 build is clearly snappy, without sums of latency, there is a huge leap in latency/input lag from the 1803 build on.
Hi. I tested the latest Retroarch version (1.14.0) on Win 10 1511, but the D3D11 and 12 drivers still don't work and the issue persists. OpenGL only. If I set video driver to D3D11 in the config file and make it read-only to avoid rewriting, Retroarch will refuse to open. Ok. Should I hold any hope it could be fixed someday, or should I give up, accept and forget about it in the name of progress, whatever it is? Anyway, a big thank you for all your fantastic work and labor of love.
The latency increase you noticed going from Windows 10 build 1511 to 1803 and higher is likely caused by all the security mitigations that were implemented from around that time. Haswell CPU's and older lack some of the instructions to minimize the performance hit. Most Intel CPU's from 6th to 8th gen and onward are minimally affected.
You could try on newer Windows 10 builds to disable those mitigations to see if latency returns to normal, but doing so maybe expose security vulerabilities with your system.
InSpectre is the only software I can think of at the moment that can disable the mitigations, though some can be disabled through powershell.
@Kaisersigmax3
R9 380x with CRT Emudriver 2.0
Are you still using this while testing the D3D drivers? Can you poinpoint the last commit that worked for you? Any idea what specific AMD Radeon driver this 'CRT Emudriver 2.0' is based on so we can take a guess as to what D3D10/11 feature level it supports?
Hi there! Thanks for all your patience!
Yes, I'm testing the D3D drivers while using the combo R9 380X + CRT Emudriver.
The D3D11 and 12 issues started with RA v. 1.9.9. The feature I really miss is the Automatic Frame Delay, but it was implemented exactly in this version.
The CRT Emudriver version I use is the 2.0 Beta 15, that's based off the Crimson 16.5.2 AMD Radeon driver.
The latency increase you noticed going from Windows 10 build 1511 to 1803 and higher is likely caused by all the security mitigations that were implemented from around that time. Haswell CPU's and older lack some of the instructions to minimize the performance hit. Most Intel CPU's from 6th to 8th gen and onward are minimally affected.
You could try on newer Windows 10 builds to disable those mitigations to see if latency returns to normal, but doing so maybe expose security vulerabilities with your system.
InSpectre is the only software I can think of at the moment that can disable the mitigations, though some can be disabled through powershell.
Hi. I have a 3rd PC here based on an i3 9350K. I tested these different W10 versions in it, and the results were the same as the 4th gen CPU: W10 1511 was clearly snappy, while everything after it had increased input latency.
InSpectre......? Never heard about it. But I never searched for something to bypass secutity in Windows anyway...
I always disable Defender and firewall.
I experience this issue on my system aswell, where trying to use D3D11 for the video driver results in retroarch crashing/closing. When relaunching retroarch, the video driver is then automatically reset to GL. Though unlike in Kaisersigmax3's case, this issue occurs since retroarch stable version 1.11.0 onwards (still works fine in v1.10.3).
I assume this effects at least all other Intel IGPs prior to Intel's 4th gen (Haswell). The main downside I noticed is that the Swanstation core becomes unusable, as this requires D3D11 to run.
System info OS: Windows 7 - 64-bit CPU: Intel Core i5-3230m GPU: Intel HD Graphics 4000 GPU Driver: 15.33.53.5161 (last released driver from 23.10.2020)
I might have one laptop with an Intel HD 4K. I could try testing if there are issues with the D3D11 driver there. Backwards compatibility is of importance to us since we'd like to default to D3D11 by default in the near future for the mainline Windows builds.
Can you maybe turn on Logging Verbosity, run RetroArch from the commandline and tell us if it reports something about 'Direct3D 11 Feature Level' or something to that effect? Tell us what version it reports
Here are the relevant last 4 lines from the log:
[ERROR] [DXGI]: Failed to get DXGI Output 6 from best output
[INFO] [D3D11]: Device created (Feature Level: 11.0)
[WARN] [D3D11]: Failed to create swapchain with flip model, try non-flip model.
[INFO] [Config]: Saved new config to "C:\Users\Lenovo\Desktop\RetroArch\retroarch.cfg".
Retroarch version: 1.15.0 (stable)
Edit: I did a quick search about "DXGI flip model", and the following quote might suggest that this is rather a Windows 7 issue than the older Intel IGP:
If you use DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL on Windows 7 or earlier operating system, device creation fails.
source: https://learn.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-flip-model
I’m also having this issue.
Using Windows 7, crt emudriver 2.0 beta 15- Crimson 16.2.1 drivers, on an AMD Radeon HD 5450, dell optiplex 7010, i7-3770.
D3D11 works fine on Retroarch 1.10. I haven’t pinpointed the exact version where it changed but it no longer works on 1.14 and 1.15. Same as the above descriptions, Retroarch simply won’t open with d3d11, and auto switches back to GL.
I’m also having this issue too. im using Windows 7 / intel hd 4000 / intel core i5-3210M D3D11 works in Retroarch 1.10. but it no longer works on 1.15.0 Retroarch simply won’t open with d3d11, and auto switches back to GL.
@EPIC3477 Just as a note, you can even use v1.10.3 as D3D11 works fine up until this version for Windows 7 users.
Does not happen here with Win10 and Nvidia.
Hi there, sonninnos! RA is constantly being updated to fit newer "ecosystems", and its d3d11 driver has definitelly been changed for the new. Win 10 build 1511 has the lowest kernel input lag, but it won't handle newer d3d11 features. It's not related to gpu brand, since it's an OS limitation. As AMD gpus offer way more flexibility for generating non standard video modes (240p/480i) and H/V frequencies (15 kHz), the CRT Emudriver is designed especially for them and, as far as I know, it only works with them. CRT Emudriver isn't even part of the issue, since there are no d3d11 issues if you use it with win10 1809 on, for the price of increased kernel latency*. Probably, if you use a Nvidia card with the Nvidia driver with win10 1511 the issue will happen as well.