It looks like the Wine project are proceeding forward with their own WineD3D Vulkan back-end, rather than using the competing DXVK as seen in Valve’s Proton implementation.
Before the discussion starts, I should note that these sorts of quotes are easy to take out of context. This is not a pro wrestling match. This is a group of developers trying to envision their roadmap. I am reporting on the bits that came out publicly (which is a lot for open-source software).
Last year, Valve Software released Proton. Proton is a modified version of Wine, which allows Windows software to be run on Linux. Valve’s version is focused on modern videogames, such as Beat Saber and DOOM (2016), and so it relies upon a good DirectX translation layer. Valve supports the DXVK project for this compatibility, which translates into Vulkan.
Henri Verbeet, the lead developer of WineD3D, wants to focus on their own Vulkan implementation for DirectX. In the Wine mailing list, it was noted that WineD3D, which I assume refers to their current OpenGL implementation, sometimes outperforms DXVK. Rather than exploring those cases, they would rather work on the examples where DXVK outperforms them.
They also mentioned, “It’s great that DXVK is working so well for some people, but it’s also ultimately a dead end.” This quote and their intention to not investigate DXVK performance regressions… strongly suggest that they want WineD3D to go its own way.
The Phoronix post adds another quote from Henri Verbeet: “The short version is that Wine’s own Vulkan D3D backend should make DXVK superfluous in the long term.”
Venn Stone of LinuxGameCast (disclosure: I support them on Patreon) also pointed me to a Reddit thread where this is being discussed. There is a little C vs C++, Make vs Meson, and “Not Invented Here Syndrome” debate going on. A lot of the comments seem to assume that one or the other must obsolete its cousin.
Personally, I don’t mind that there are two (or more) independent compatibility layers on the market. It would be nice if one was perfect, and working together could help that, but there is also merit in using the best tool for any given job. I am the type of person who uses several web browsers simultaneously, with certain sites delegated to certain browsers.
For example, Tweetdeck used to run terribly on Firefox and Chrome, so I started using it in Opera, which had the added benefit of not doing much else besides Tweetdeck. There was a time (a few years ago) that Twitch and other long videos used to chug after about a half hour, so I left that to run on Edge. Most of my research is done in Firefox. Chrome used to be where I loaded Flash applications so I could leave it uninstalled everywhere else.
The point of the above anecdote is that sometimes having multiple choices is good. It’s very difficult to write perfect software. You often end up with trade-offs. Ideally, the Linux software would be written to natively support the operating system, so the concept of “which compatibility layer is best” should not even happen. Windows has a huge library of games though, so there is value, and will continue to be value. I don’t see someone going back and re-writing every Windows game that’s worth playing since the 1990s.
On the other hand, I can see the desire to simplify just wanting to play a video game. Having the mental matrix of which games play best with what shim might get a bit annoying. That should be traded off with using the best tool for the job, although the desire to have one winner sounds more like a user experience problem.
Either way, it looks like two solutions will be developed in parallel. One may win, the other may win, or both may serve a specific set of purposes.
With your analogy of running multiple browsers on the same OS, are you saying that Wine users can be running both WineD3D and DXVK on the same OS?
You can run Wine and Proton on the same PC.
I run all my non-native Linux games through Lutris, it takes care of which translation layer works best for a certain application.