https://bugs.winehq.org/show_bug.cgi?id=57834
--- Comment #15 from Zeb Figura z.figura12@gmail.com --- The reason for the performance gap between DXVK and Wine's builtin D3D implementation (and, similarly, between vkd3d-proton and vkd3d)—such as it existed and sometimes still exists—has nothing to do with the underlying API, and everything to do with the amount of developer time that has been spent on each implementation.
There is no magic modern Vulkan feature that improves performance as significantly as people somehow think, and even if there were, the desire to support a broad range of Vulkan drivers, including MoltenVK, does not actually prevent us from using any such features.
The idea that "DXVK is focused on performance, whereas Wine is focused on compatibility" (or sometimes "correctness") is widespread, and completely wrong. Anyone who's spent time actually looking at the Wine codebase can find plenty of evidence that Wine is focused on performance. Fun fact also, we've got a whole database of targeted workarounds for driver bugs, or special code to avoid driver paths that are known to be slow; some people think we leave performance on the table because we refuse to do that and that's not correct either.
The only sense in which that's true is that, after 20 years of experience, we care quite a lot about designing the code to be maintainable and readable. We also care quite a lot about avoiding regressions. This leads to a style of development whereby large changes are planned out, and we attempt to account for all of the corner cases, before implementing things, it means writing tests, and it means we split changes into patches that a reviewer can easily understand. DXVK follows pretty much the opposite style of development as this. The effect is that DXVK can get one application working a lot faster, and then has to spend a lot of time fixing bugs and regressions, whereas we have to spend comparatively little time fixing bugs but it takes a lot more time before a feature is fundamentally ready.
In 2018, back when DXVK was starting to work well for a few applications, half of Wine's Direct3D team—then about four people—was contracted to work on vkd3d, bringing it up from scratch to a fundamental implementation. The other half was still working on d3d9, as well as things like GL core profile support. Despite this they still managed to spend some time on d3d11, but they had quite a lot of things to implement:
(1) An entire Vulkan renderer—as it became clear would be necessary, not because Vulkan "allows better performance" (it doesn't, not really, except for some very stupid missing pieces in GL that don't have anything to do with the latter's design flaws) but because it was becoming clear that Khronos and driver developers would abandon GL.
The amount of time that Vulkan, with its stupid API break and even stupider API design, has cost us, and is continuing to cost us, cannot be stated enough, and I find it infuriating because nobody who talks about Vulkan ever acknowledges this.
(2) Direct3D 11 deferred contexts, which prevented a lot of games from working. Michael Müller wrote an implementation for this, but it was bolted on like spaghetti and didn't really allow for optimal performance. "Why didn't you just commit those patches?"
(3) Map acceleration across the command stream, which killed performance for anything d3d10/d3d11 and many things d3d9. This was what Andrew Comminos' "PBA" patch set was supposed to fix, but it was bolted on like spaghetti and arranged in an unreviewable way. "Why didn't you just commit those patches?"
By the way, one of the "stupid missing pieces" in GL is *still* killing performance in a way related to this. We'd like to switch to the Vulkan renderer by default, which is actually on par with DXVK in most games I try, but we can't do that until it's as featureful as the GL backend (doesn't cause regressions), which takes a lot of work!
Meanwhile, DXVK—in addition to following a different development model—was being written by a very talented individual who, importantly, had the free time to do nothing *but* work on d3d11, *and* moreover Philip was working on a new code base, without the need to worry about things like d3d9 or GL. This meant that he was able to get a few high-profile applications working very well a lot more quickly than Wine could, which naturally attracted a lot of attention.
Over the years that followed, the amount of time that CodeWeavers has spent on Linux Direct3D has only shrunk. We lost Józef, one of the most talented and productive members of the team, and while we've gained several other people since then (including myself), CW has spent all of the D3D team's time on MoltenVK (which is where pretty much all of the deficiencies are in the 3D stack on Mac), the HLSL compiler, and various client bugs not related to 3D. At this moment nobody is working on d3d12, and the only person working on ddraw-d3d11 is what little time I can spare that's not one of those other things, and all of tha time is *still* focused entirely on the fall out of the stupid @%$!! mess that is Vulkan. Have I mentioned how much I hate Vulkan?
Meanwhile, all of the big 3 problems I listed have been fixed, several years ago in fact, and Wine's d3d11 implementation is actually quite good. But nobody has noticed, both because everyone's attention is on DXVK, and because optimal performance still relies on Vulkan, which can't be the default yet. And when there are bugs—and several users I am infinitely thankful towards are still reporting them—I simply don't have the time to do anything about them.