Yesterday I made the mistake of responding to a bug report asking about Vulkan support in wined3d. Someone thought it was a good idea to inform Michael Larabel, and it's gone pretty much downhill from there. The smart thing to do would probably be to ignore the subject after that, but I nevertheless wanted to clarify a few things for my fellow members of the Wine community, and give them a chance to ask any questions.
To the careful observer, this development shouldn't be all that surprising, of course. Vulkan is a major graphics API, arguably it's the only reasonable way for Wine to get access to modern graphics on MacOS (yes, Metal exists, but...), CodeWeavers has done some work on MoltenVK in the past few months, and wined3d has seen some (modest) work on separating the OpenGL specific parts from the common parts in the past few months.
One question a number of people seem to have is why this didn't happen sooner, so let me try to give some background there. As many of you are aware, one of the realities of commercial software development is that—with perhaps a few notable exceptions—customers have significant influence on what the relative priorities are of what you get to work on. I should give CodeWeavers significant credit for the fact that Wine maintainers at CodeWeavers enjoy a relatively large amount of independence, but in any case, for various reasons the focus at CodeWeavers was really on Direct3D 9 support, up until about 2015. Some of those reasons include there really not being a lot of Direct3D 10 applications, and once Direct3D 11 became significant a lot of those applications supporting Direct3D 9 as well, but also the fact that OpenGL support on MacOS had been stagnating for a while, and a bunch of required functionality just wasn't available. Somewhat ironically, one of the things that ended up pushing Direct3D 10/11 support forward was Office 2013/2016, and its usage of Direct2D.
Unfortunately that push was short-lived. In early 2016 (i.e., a few months after the initial public Vulkan release) we were approached to do an implementation of Direct3D 12 on top of Vulkan, the result of which is the vkd3d project. I thought that was unfortunate for a few reasons, one of which was that CodeWeavers had already announced making a push on Direct3D 11, and another of which was that even today there aren't all that many Direct3D 12 applications.
The bottom line is that the answer to the question why this didn't happen sooner is mainly that between the public release of Vulkan and now, we didn't have the resources. There were a few other considerations that might have played a role if we had had the resources, like the lack of stream output / transform feedback in Vulkan (now resolved), Vulkan pipeline compilation speed, and a few others, but those are all moot as long as there's nobody to do the work.
The other thing people seem to want to know is "Why not DXVK?". On first sight, you might say DXVK is written in C++, uses a non-copyleft license and duplicates a bunch of existing Wine code for no good reason, while Wine would obviously prefer C, LGPL, and something that fits into the existing architecture of Wine. I.e., at the outset, these really aren't the design decisions you'd make if your goal is to eventually become part of the Wine project. Nevertheless, those things wouldn't be disqualifying per se.
I learned about DXVK either near the end of 2017 or near the start of 2018. In February 2018, we reached out to Philip Rebohle—the author of DXVK—to start a conversation around whether there were any areas we could cooperate on. One obvious area was the vkd3d shader compiler, which translates Direct3D shader byte code to SPIR-V (much like DXVK has to do), but there would have been other possibilities, like sharing the DXGI implementation, or using a scheme like vkd3d where Wine's d3d11 could have optionally loaded DXVK as a regular shared library. That e-mail went unanswered. Now, I appreciate that different people have different ideas about what's acceptable and what isn't, but personally I think that's extremely rude and uncivilised. Nevertheless, e-mail gets lost sometimes, sometimes people are busy, everyone gets a second chance. So a few months later, since I was organising WineConf 2018, I sent Philip a personal invitation to attend WineConf, and perhaps discuss things there. That invitation went unanswered too, at which point I was pretty much done with DXVK. It is my understanding that since then both Jeremy White and CodeWeavers' partners at Valve have tried reaching out to Philip on the subject, but evidently with little success.
Bottom line, cooperation only works if both sides are trying.
There's one more issue I'd like to address, which isn't about the wined3d Vulkan backend—also known by its internal codename "Damavand"—but rather about certain comments along the lines of "Wine should accept C++ code", "Wine maintainers are mean because they didn't accept my patch", etc. Leaving aside for the moment the fact that none of those were the issue with DXVK, that's really not how this works. Like any project, the Wine project has certain rules, certain guidelines, and certain standards. Some people may disagree with some of those, that's fine. Perhaps some people would like to see some rules or guidelines changed, standards raised or lowered. That's fine too, and the way to go about that would be to become a well respected member of the Wine community, make your argument, and perhaps if enough people find your argument convincing, it may even happen. On the other hand, shouting from the sidelines, on the internet, is rather unlikely to be effective. Similarly, a lot of these rules, guidelines and standards are well known even outside the Wine project. If you knowingly start some project that conflicts with those, best of luck to you and we hope you have fun, but it's really not on the Wine project if that code then doesn't end up going into upstream Wine. And last, but not least, "Wine developers should work on what I tell them to". No.
Henri
-
Henri Verbeet