wined3d/Vulkan

[Henri Verbeet]

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