This means that VKD3D and DXVK will be able to utilize new extensions. It’s a necessary step forward, but does exactly nothing to performance by itself.
As already mentioned a few times by others (although not very explicitly indeed), in order for you to see FPS gains in DX-12 games, the whole software stack needs to support the new extension:
- at the bottom you have a GPU (NV) Vulkan driver: that’s moving fairly fast in NV’s VK beta branch: Vulkan Driver Support | NVIDIA Developer
- Wine emulation layer needs to re-expose the new API to Windows DLLs and programs, that’s what has been done in the patch I linked previously: winevulkan: Update to VK spec version 1.4.340. (!9954) · Merge requests · wine / wine · GitLab
- not 100% sure, but you probably also need the corresponding Vulkan-loader to glue the above 2 together. This has been released 2 days ago: GitHub - KhronosGroup/Vulkan-Loader at v1.4.340
- at the top level, DX-12 implementation (VKD3D-proton DLLs) needs to be updated to use the new extension. This together with NV’s VK driver is where the most significant changes need to happen. To my knowledge, there’s no public patch related to this yet.
UPDATE: Prototype implementation of VK_EXT_descriptor_heap by HansKristian-Work · Pull Request #2805 · HansKristian-Work/vkd3d-proton · GitHub - now because VKD3D-proton depends on certain parts of DXVK (that implements older versions of DX), certain changes need to happen there as well: that’s what is being done in this PR: Descriptor Heaps by doitsujin · Pull Request #5465 · doitsujin/dxvk · GitHub (the fact that this is not finalized yet is probably the reason why nothing has yet been published in VKD3D-proton)
UPDATE: I’m not actually sure if the shared part (DXGI) has anything to do with the descriptor heaps extension, so it is possible that VKD3D-proton may not be blocked on the mentioned PR.
It is possible that this PR will also slightly improve performance of older games BTW (those using older versions of DX). Given that they are currently on-par with Windows, it is possible that they will be performing noticeably better on Linux after everything is ready (it’s just a speculation at this point though).
So, no: at this stage the Wine patch on its own will not give you any FPS gains. It is just one of the pieces of the whole stack.
Thanks for the detailed explanation.
What I’m curious about:
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?
I’d love to do some beta testing as soon as they come out!
This has been developed privately alongside the Vulkan specification, that’s why most updates have been in the pipeline already and patched so fast.
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.
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.
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
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.
that sucks, I hope it’s not going to take THAT long… a whole another year sounds so depressing. Hope they can get to there at least q3 2026, I really hope for it to finish in Q2, sounds too positive I know, but dang.
Will this improve things other than proton (translated games) such as cs2 which has native vulkan on linux?
Programs that use Vulkan directly, would need to be patched directly by their developers to take advantage of the new Vulkan feature.
However, it seems to me (please correct me if I’m wrong: I’m not much of a gamer), that such games are on par between Win vs Linux, no? The problem with DX-12 on Linux was due to a difference in programming models between DX-12 and NV’s Vulkan (oversimplifying: one DX-12 call had to be translated into several VK calls which creates a lot of overhead, and now it’s somewhat closer to 1-to-1), so if you use VK directly, you shouldn’t have such problems.
Well, on Linux CS2 performs better than on Windows 11. However, GPU utilization on my 5090 is pretty low, so I’m assuming there’s a lot of optimization that could be done to further improve the performance.
My question is: Do these new functions theoretically have benefits over current natively implemented calls with the old methods?
Emulation on Linux using NVIDIA is worse compared to Windows using the Vulkan backend.
I’m hoping this Vulkan update will also affect emulation. I think the benefits go beyond translation.
It is possible, but I’d rather bet that you may be bottlenecked by other factors: CPU, VRAM size + PCIe transfer speed etc.
I don’t know Vulkan well enough to answer this: hopefully others will be able to tell more.
Well…I don’t believe there’s much more to gain here. 5090, 9800x3d, 6000CL30 RAM etc.
Valorant has significantly higher and more consistent FPS. So I do believe there’s something to be “gained”. I’m just not sure if it’s something where the new Vulkan changes could benefit it, or if the issues are coming from somewhere else (general game optimization / engine issues).