Why doesn't Wine include DXVK (DirectX to Vulkan translation) by default? It supports Direct3D (and DirectX) 8/9/10/11
I had a DX11 issue with a Windows game on macOS (bug #58145), which was solved by setting native DLL overrides for d3d10core and d3d11 using Gcenx's DXVK-macOS fork (which only supports D3D/DX 10/11 on macOS)
Why doesn't Wine include DXVK by default?
Re: Why doesn't Wine include DXVK by default?
another question: does this mean that a default install of Wine (without DXVK) translates D3D/DX calls to OpenGL by default? Is it different on macOS vs Linux?
Re: Why doesn't Wine include DXVK by default?
[To forum stuff: the below post was definitely not generated by any AI, I wrote it myself. Please kindly approve it or be more specific why it cannot be approved, so that I can improve it. Thanks!]
DXVK (and DXVK-NVAPI and vkd3d-proton to that matter) are 3rd party projects with their own release cycles, issue tracking etc. Bundling separate projects together is a proprietary (M$, Apple) custom where the main goal is to vendor-lock-in users. In case of FOSS systems, the goal is to keep things modular and interoperable, so that individual subsystems can be easily replaced depending on user needs and taste.
Ideally, DXVK (and the above mentioned rest of the gang) should be packaged (and possibly set as the default option over wined3d) by Linux distros. The problem is however that DXVK DLLs need to be installed in each user's `WINEPREFIX` folder, while distro packaging mechanisms (like deb or rpm) are designed to manage system-wide folders (like `/usr`, `/bin`, `/lib`, `/etc` and so on) and not mess with user home folders. A solution to this would be a patch to `wineboot` that makes it check some well-known folder for available extensions when creating/updating a `WINEPREFIX` folder, but I guess that no one bothered to develop such a feature.
DXVK (and DXVK-NVAPI and vkd3d-proton to that matter) are 3rd party projects with their own release cycles, issue tracking etc. Bundling separate projects together is a proprietary (M$, Apple) custom where the main goal is to vendor-lock-in users. In case of FOSS systems, the goal is to keep things modular and interoperable, so that individual subsystems can be easily replaced depending on user needs and taste.
Ideally, DXVK (and the above mentioned rest of the gang) should be packaged (and possibly set as the default option over wined3d) by Linux distros. The problem is however that DXVK DLLs need to be installed in each user's `WINEPREFIX` folder, while distro packaging mechanisms (like deb or rpm) are designed to manage system-wide folders (like `/usr`, `/bin`, `/lib`, `/etc` and so on) and not mess with user home folders. A solution to this would be a patch to `wineboot` that makes it check some well-known folder for available extensions when creating/updating a `WINEPREFIX` folder, but I guess that no one bothered to develop such a feature.
-
zukote1991
- Newbie
- Posts: 1
- Joined: Mon May 12, 2025 11:19 am
Re: Why doesn't Wine include DXVK by default?
The main reason Wine doesn't include DXVK by default is because DXVK depends on Vulkan support, which isn't universally available or stable across all platforms Wine targets — especially macOS. Wine aims for broad compatibility without relying on external components that might introduce additional dependencies or licensing concerns. That said, many users manually install DXVK where it makes sense, just like you did. Your experience with Gcenx's macOS fork is a good example of how DXVK can help in specific cases even if it’s not bundled directly.
