DirectX 12 games ran through Proton/Wine on Linux perform so much worse compared to Windows. This can’t be just the overhead from the translation as AMD GPUs perform just fine, but I think it’s due to a lack of proper driver optimizations. DXVK and VKD3D developers have acknowledged this and they can’t do much about it due to the driver’s closed source nature. They can’t tell how exactly it works behind the scenes. I don’t know if this is talked about enough, but I don’t see the top threads covering his topic. I think it has high priority. I hope Nvidia developers at least take a look at this and maybe optimize things if they can. Nvidia GPUs are great on Linux when it comes to computation/CUDA, etc, but for real time applications they are sadly not performing optimally at the moment. Update, more information: Driver version is pretty much irrelevant, this applies even today, same goes for Proton/Wine/vkd3d/dxvk – I have been using Linux for about 3 years, and it has always been considerably slower for directx12 titles Wayland improves performance compared to x11, which is an interesting behavior that might help pinpoint the issue Hardware-wise, Pascal and older GPUs experience this more severe, Turing and newer are better but they are still considerably slower than Windows CPU heavy software like emulators or some games suffer more From what I can tell, this happens regardless of hardware (CPU, RAM, etc), as long as you are using an Nvidia GPU Here’s a video comparing performance on Linux and Windows on an Nvidia GPU (4080 Super) under x11: [Nvidia 4080 Super: Linux vs Windows Performance Battle] I will update the post later when I have time to dualboot to give my own numbers, but my experience matches the video. An example of a game I’m currently playing is Resident Evil 4 remake. On Windows I get 80+ FPS, while on Linux I get from 40 to 75 depending on where I am at the same settings. On x11 it gets down to the 30s, so running Wayland actually gives me reasonably higher framerate, which is definitely nice, but I know things can be even more optimized. My own hardware: 2060 super 3700x 16gb ram Arch Linux Kde Plasma 6.1.4

[image] Rnk0: How far did prior knowledge of this extension go? Did the DVK3D and Proton know about this and therefore start prior work? Does anybody know the status of the development? This has been developed privately alongside the Vulkan specification, that’s why most updates have been in the pipeline already and patched so fast. [image] morgwai666: now because VKD3D-proton is built on top of DXVK (that implements older versions of DX), I don’t think it is built on top of DXVK… VKD3D is a pure C implementation meant to be published as part of wine (which also is C only) and is meant to replace the old wined3d implementation (which used OpenGL) while DXVK is a pure C++ implementation targeting specifically DirectX 11 (but now also older versions) to work around wined3d inefficiencies by using Vulkan. But both projects managed to rely on a merged protocol basis now (e.g. they use the same DXBC code paths now as far as I know, this was done mainly for proper co-existence). VKD3D-proton is based on VKD3D of the wine project, tho. I’m not sure, tho, if vkd3d (the wine component, not the Proton component) as a wined3d replacement is supposed to support all versions of DX which wined3d supports. But vkd3d-proton specifically targets DX12 only. I think both projects have their very own root ideas and only lately merged some efforts. That said, vkd3d-proton may need some more time to backport some of the new code to vkd3d in wine. I’m not sure if vkd3d-proton is a completely independent fork or if it tries to stay as close to the wine vkd3d as possible to minimize code differences. Or the amount of work to change how descriptor buffers work is just much larger in vkd3d… We also need to keep in mind that vkd3d has to continue working with and without the new Vulkan extension, and such fallback paths usually make code complicated and harder to test. In contrast to DXVK, vkd3d is probably much more tightly integrated with descriptor buffers because of how DX12 works, while in DXVK they are more abstract to the client application and DXVK can use it however it wants.

[image] hurikhan77: I don’t think it is built on top of DXVK… From VKD3D-proton’s README: vkd3d-proton does not supply the necessary DXGI components on its own. Instead, DXVK (2.1+) and vkd3d-proton share a DXGI implementation. UPDATE: I’m however indeed not 100% sure if any changes specifically in DXGI are necessary for the descriptor heap extension.

Yes, they share a common code path now - as I wrote. But it doesn’t mean one implementation is based off the other. The problem has been that applications would see DX11 and DX12 as different GPUs until they started to share a common DXGI implementation - if I remember correctly. You can probably say one depends on the other for certain updates. But I don’t think that DXGI does anything which affects how descriptor buffers are exposed. I think it’s rather an interface to present which feature levels each GPU supports, which monitors are available, how resources are shared, how presentation works… It’s mostly graphics infrastructure but going quite low level. DX12 apps should not see how descriptor buffers are implemented exactly, that’s what vkd3d hides and emulates when translating to Vulkan, and that emulation part made it slow especially with NVIDIA.

[image] hurikhan77: But I don’t think that DXGI does anything which affects how descriptor buffers are exposed. Thanks for pointing: I’ve updated the previous posts with a notice that this may not be related. UPDATE: I’ve just had a look and so far none of the commit messages from the PR mentions changes to DXGI, further suggesting that this is unrelated indeed.

There’s now a draft PR for vkd3d-proton: Prototype implementation of VK_EXT_descriptor_heap by HansKristian-Work · Pull Request #2805 · HansKristian-Work/vkd3d-proton · GitHub

[image] gilvbp: Reddit - The heart of the internet check the first benchmark! here I would note that the person posting on there is not the VKD3D developer, and is just seemingly attempting to use the early prototype pull request and cobble it together with other things. I realize it’s the internet, but I very strongly caution people to wait until the VKD3D update is further than a prototype.

And as I already feared, it’s a (quote on quote) “glorious mess” to have both code paths in parallel… Let’s hope Hans will be able to make this work in an elegant and maintainable way, otherwise it will haunt us for years. Given the PR message, I think this PR is currently in the process of getting it work correctly somehow, and only then performance and integration work will be done. This means, DX12 - even with the new code paths - will probably continue to have a few really rough performance edge cases for some time. So yes, we may get the new extensions in Q2 2026, but we may only get good performance by the end of 2026 because the piece of software where it really matters, needs a really complicated implementation. But the work on code is open now, others can chime in and help out. There are many genius people out there, maybe a miracle happens. :-)

We have to be careful about interpreting this +20% result. He reports a lot of visual artifacts, which must be caused by lack of alignment between APIs. I would be careful before making overreaching conclusion, since the incomplete rendering may intrinsically lead to better performance. The encouraging news are the progress and that now these extensions are being worked in the open.

I agree… I’d still expect that we can get something like 20-30% improvement because that’s what the DX12 performance lacks behind compared to Windows drivers in many cases. There will be other limiting factors like GPU memory management which is a complete different discussion, so the driver will probably still stay behind AMD until all the other issues are resolved (relatively speaking). The current prototype branch is something which completely rips out the old rendering pipeline, it misses some functions as there are rendering artifacts, it is not optimized yet. And even the NVIDIA driver implementation isn’t probably final yet as it hasn’t been battle-tested with games and translation layers in the wild yet. For now, the prototype is about getting the implementation correct, so no more rendering artifacts, no freezes, proper locking and parallelism. This will also be true for the NVIDIA side of things. So it will probably lower the performance a little because, as of yet, the prototype doesn’t yet implement all the things it needs to do. Next step is integrating the prototype back into the existing implementation, working around the “glorious mess”, which will further lower the performance. This will be the most rough phase of the project and probably last quite some time. I think we’ll be at the end of the year at this point already. Final step is optimizing the general code base, which finally brings the real performance, then more per-game optimizations will follow. So the real performance improvements will probably not land before 2027. So for now, let’s keep expectations realistic, and let’s not decide early whether we have a good implementation already or final results - we just won’t. It will be a lot less exciting at the start than people expected or hoped.

DirectX12 performance is terrible on Linux

Graphics / Linux Linux

gilvbp January 26, 2026, 7:44pm 638

Reddit - The heart of the internet check the first benchmark! here

Topic		Replies	Views
Native DirectX 12 on Linux Linux	75	2398	November 10, 2026
Please sort out the DX12 (vkd3d-proton) performance under Linux Linux	7	9209	October 10, 2026
610 release feedback & discussion Linux	301	43217	October 12, 2026
BUG: Indiana Jones and the Great Circle only runs at ~40% of max TDP on RTX 4090 Linux	87	23748	January 17, 2025
VRAM Allocation Issues Linux	92	34899	October 29, 2026
Low performance in DOOM Eternal Linux	38	11872	June 23, 2021
Starfield does not launch on most NVIDIA GPUs on Linux, and not at all on Pascal GPUs Linux linux-driver	175	49554	December 14, 2023
Non-existent shared VRAM on NVIDIA Linux drivers Linux	158	43570	October 29, 2026
Extremely poor performance on a few selected applications Linux	0	2244	January 16, 2016
555 release feedback & discussion Linux	275	51927	January 10, 2025

DirectX12 performance is terrible on Linux

Related topics