DXVK lead developer Philip Rebohle is about to put his project into maintenance mode.
DXVK is a layer that converts D3D10 and D3D11 calls to Vulkan instead of OpenGL, thereby adding performance in games. But at this stage, difficulties arose.
According to the author of this project:
It's because DXVK has become a fragile, unreliable and frustrating maintenance nightmare. Most of the 1.4.x releases introduced major regressions which I cannot reproduce, and therefore cannot debug and fix.
This includes GPU hangs in Overwatch on specific maps with Nvidia GPUs (some users claim it's fixed in 1.4.6 while others still have them), rendering issues in Dishonored 2 which I can't reproduce (see ValveSoftware/Proton#823 (comment)), vertex explosions in some games which I also can't reproduce, an ongoing Star Citizen issue which I still need to debug (see #1262), and tons of weird issues that don't make any sense whatsoever (like #1266 which only seems to affect RADV).
Most of these problems are still unresolved and I have no idea how to even track them down, let alone fix them, and the ones that got "fixed" got fixed by reverting otherwise useful changes because I simply do not understand any of the issues at all.
Doing any sort of active development with this broken mess of a code base would only make this worse, and I wish I had drawn the line sooner. The only thing I still plan to do is wire up some useful Vulkan extensions and eventually merge D9VK, the rest will be bug fixing only.
He also reports that his main problem is that he simply does not understand most of the problems that have been appearing everywhere lately. There are some things that some cleanups can use, but recent attempts to do this have caused exactly the type of regression in which touching something leads to some kind of arbitrary breakdown for no particular reason.
Philip Rebohle noted that when manually detecting crashes or errors for functions where it matters, a lot of problems arise:
- We can't debug GPU hangs this way, at all. This needs GPU-side work, and obviously extra code on the CPU side to actually do that.
- Even if purely CPU-side debugging is useful (e.g. when something segfaults), demanding games easily do >10 million API calls per second. Logging all of those, plus all the backend work, would be insane.
- There's just so much going on on multiple threads that just spamming messages everywhere won't necessarily make it easier to figure out what the actual problem was. Wine's debug channels kind of have the same problem; if things don't work due to an unimplemented feature it's easy to figure out; if the problem sits deeper than that, it often isn't.
The only thing he still plans to do is plug in some useful Vulkan extensions and eventually merge D9VK, the rest will only be bug fixes.
See the discussion of this topic here.