DXVK DirectX To Vulkan Translation Layer Development Halts To A Grind
The main developer of DXVK will no longer be adding features the optional DirectX 10/11 to Vulkan translation layer for WINE "because DXVK has become a fragile, unreliable and frustrating maintenance nightmare." DXVK is a crucial part of Valve's Proton layer used to run Windows games on their Steam games store.
published 2019-12-12 - last edited 2020-07-15
The Windows-game Monster Girl Island running under Wine using DXVK to translate its DirectX 11 draw calls.
There has been no official announcement as of yet. The main discussion is apparently taking place on some proprietary heavily surveilled chat system called "Discord". The reasons why DXVK development just seized are explained by the German lead DXVK developer and maintainer Philip "doitsujin" Rebohle in a github comment on a VXVK pull request as:
"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, 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."
December 11th, 2019
Philip "doitsujin" Rebohle elaborates on the reasons why it is so hard to track down rendering problems and other issues that are piling up in the bug-tracker:
"My main issue is that I simply don't understand most of the issues that are popping up everywhere lately, not that the code base itself is poorly structured. There are some things that could use some cleanups, but the last attempts at doing that have caused exactly the kind of regressions I was complaining about, and it really seems like touching anything causes some arbitrary breakage for no particular reason.
I don't know if we're running into driver issues (could be given that these things tend to be limited to a single vendor) or if there's some insane case of undefined behaviour going on in my code (of course dxvk being a windows library makes it a lot harder to debug such things since none of the standard tools like valgrind work properly), but it doesn't really matter either way, breakage is bad and should be avoided."
December 11th, 2019
Our sources within the AMDGPU developer community[1] confirm that issues related to DXVK are a nightmare. Their RADV Mesa driver for Vulkan is free software but everything else is essentially a black box. The Windows games and console emulators people run are closed source and DVXK itself is a Windows library which can't be debugged using the regular tools. This makes it really hard to understand exactly what is going on.
Debugging DXVK issues even worse to when the proprietary Nvidia graphics driver is used; in that case you have a closed-source black box graphics driver and black box games with DXVK smacked in the middle. Most of the DXVK bugs are reported by users of Nvidia's proprietary binary blob driver. This does not necessarily mean that there are more issues with Nvidia's closed-source driver than there are on the AMD side; the vast majority of gamers are using Nvidia GPUs.
WINE's Built-In Alternative[edit]
The Wine compatibility layer for running Windows software on GNU/Linux distributions comes with its own built-in DirectX 10/11 translation layer which translates draw calls to OpenGL. DXVK is an optional alternative which is available in most distributions as a package called wine-dxvk or dxvk-bin (Arch/Manjaro). DXVK's use of Vulkan makes it slightly faster than Wine's built-in OpenGL translation layer and there are some other differences - but it's not like DXVK is required to run DX10/11 software on GNU/Linux systems. Windows games would still run on GNU/Linux machines if DXVK were to disappear tomorrow. It won't, it will still be around but there will be no more features added to it any time soon. Changes to future versions will consist of small bug-fixes if/when it is possible to understand the nature of the pile of mysterious bugs that are listed in DXVK's issue-tracker.
Domino-Effect On Steam[edit]
The GNU/Linux version of Valve's Steam games store and launcher has its own Windows compatibility layer called Proton. Proton is built using off-the-shelf free software like vkd3d for DirectX 12, DXVK for DirectX 10 and 11, D9VK for DirectX 9 and FAudio for proper audio support. Proton will therefore be dramatically affected by the halt of DXVK development since it is a core part of Valve's "Proton" product. It will be interesting to see how Valve reacts. They could just drop DXVK and use Wine's OpenGL translation layer for DX11/DX12. They do, as a medium sized company, have the ability to throw paid developers DXVK's way.
The close-to announcements from DXVK developer Philip "doitsujin" Rebohle regarding its shift to what he calls "maintenance mode" and discussion around that topic are on DXVK's GitHub page under a pull-requests titled WIP: Native Port #1264. DXVK's homepage/source code repository is at github.com/doitsujin/dxvk/.
- ↑ #radeon on Freenode
Enable comment auto-refresher