Arch Linux User Repository

DXVK upstream just merged d3d8 support, so I updated our setup script. Be sure to re-run it to enjoy DXVK's shiny new d3d8 frontend!

WINEPREFIX="/path/to/your/prefix" setup_dxvk install --symlink

This package provides Windows binaries of the DXVK dlls. They work on wine and should work on Windows too. If you don't specifically want Windows binaries and you want to just use DXVK on wine, the winelib package is a better approach and much easier to build (dxvk-winelib-git).

To enable DXVK in a wineprefix, do the following (with the WINEPREFIX variable properly set):

setup_dxvk install

In order to uninstall DXVK from a wineprefix:

setup_dxvk uninstall

Seems there are new submodules, even recursive ones need to be added.

diff --git a/PKGBUILD b/PKGBUILD
index d33ba3d..64587ca 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -18,14 +18,17 @@ source=(
     "git+https://github.com/Joshua-Ashton/mingw-directx-headers.git"
     "git+https://github.com/KhronosGroup/Vulkan-Headers.git"
     "git+https://github.com/KhronosGroup/SPIRV-Headers.git"
+    "git+https://github.com/doitsujin/dxbc-spirv.git"
+    "git+https://github.com/doitsujin/libdisplay-info.git"
     "setup_dxvk.sh::https://aur.archlinux.org/cgit/aur.git/plain/setup_dxvk.sh?h=dxvk-bin"
 )
-sha256sums=("SKIP"
-"SKIP"
-"SKIP"
-"SKIP"
-"2ca9ece1b6c36446e9f6955d3d03ab72b173c8f85539a2848febc51b38be705e"
-)
+sha256sums=('SKIP'
+            'SKIP'
+            'SKIP'
+            'SKIP'
+            'SKIP'
+            'SKIP'
+            '2ca9ece1b6c36446e9f6955d3d03ab72b173c8f85539a2848febc51b38be705e')


 pkgver() {
@@ -41,6 +44,17 @@ prepare() {
     git config submodule.include/vulkan.url "$srcdir/Vulkan-Headers"
     git config submodule.include/spirv.url "$srcdir/SPIRV-Headers"
     git -c protocol.file.allow=always submodule update include/{native/directx,vulkan,spirv}
+
+    git submodule init subprojects/{dxbc-spirv,libdisplay-info}
+    git config submodule.subprojects/dxbc-spirv.url "$srcdir/dxbc-spirv"
+    git config submodule.subprojects/libdisplay-info.url "$srcdir/libdisplay-info"
+    git -c protocol.file.allow=always submodule update subprojects/{dxbc-spirv,libdisplay-info}
+
+    cd subprojects/dxbc-spirv
+
+    git submodule init submodules/spirv_headers
+    git config submodule.submodules/spirv_headers.url "$srcdir/SPIRV-Headers"
+    git -c protocol.file.allow=always submodule update submodules/spirv_headers
 }

 build() {

Might be the same build failure that @niobium93 encountered (can't verify since the paste is 404), currently you get this error when building:

[75/370] Compiling C++ object subprojects/dxbc-spirv/libdxbc_spv.a.p/spirv_spirv_builder.cpp.obj
FAILED: subprojects/dxbc-spirv/libdxbc_spv.a.p/spirv_spirv_builder.cpp.obj 
x86_64-w64-mingw32-g++ -Isubprojects/dxbc-spirv/libdxbc_spv.a.p -Isubprojects/dxbc-spirv -I../../dxvk/subprojects/dxbc-spirv -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -fno-exceptions -std=c++17 -O3 -MD -MQ subprojects/dxbc-spirv/libdxbc_spv.a.p/spirv_spirv_builder.cpp.obj -MF subprojects/dxbc-spirv/libdxbc_spv.a.p/spirv_spirv_builder.cpp.obj.d -o subprojects/dxbc-spirv/libdxbc_spv.a.p/spirv_spirv_builder.cpp.obj -c ../../dxvk/subprojects/dxbc-spirv/spirv/spirv_builder.cpp
In file included from ../../dxvk/subprojects/dxbc-spirv/spirv/spirv_builder.h:11,
                 from ../../dxvk/subprojects/dxbc-spirv/spirv/spirv_builder.cpp:7:
../../dxvk/subprojects/dxbc-spirv/spirv/spirv_types.h:1:10: fatal error: ../submodules/spirv_headers/include/spirv/unified1/spirv.hpp: No such file or directory
    1 | #include "../submodules/spirv_headers/include/spirv/unified1/spirv.hpp"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

Package fails to build. Logs

Probably needs extra setup for new git submodule.

Indeed, we forgot to update the script for this package.

Should be fixed now.

Apologies if I'm not understanding correctly, but it seems like setup_dxvk incorrectly installs 32bit .dll files in 64bit prefixes.

I setup this Arch install in January 2025, my main ~/.wine prefix is 64bit with wow64 from what I can tell.

setup_dxvk install installs /usr/share/dxvk/x32/*.dll to $WINEPREFIX/dosdevices/c:/windows/system32.

I believe the correct behavior would be to install /usr/share/dxvk/x32/*.dll to $WINEPREFIX/dosdevices/c:/windows/syswow64 and /usr/share/dxvk/x64/*.dll to $WINEPREFIX/dosdevices/c:/windows/system32.

I had to copy the files over manually in this manner to get a d3d11 game working, it otherwise crashed a few seconds after launching.

For context, the parallel setup_vkd3d_proton script from the vkd3d-proton-mingw-git package seems to correctly install 64bit and 32bit libraries to system32 and syswow64 respectively. That script seems to have a more robust check for the prefix's architecture, checking system.reg and other context clues as well; might be a good idea long term to switch to something similar?

In any case, the issue seems to stem from line 81 of setup_dxvk.sh: in 64bit wine with wow64, there is no wine64 executable, so the win64_sys_path variable ends up empty. Aliasing like wine64=$wine is not enough, because then the script installs both the 64bit and 32bit libraries to system32, so the 64bit ones are overwritten, with the same broken result.

With wine-staging 10.4 and a fresh prefix running setup_dxvk install only installs in system32 folder and a weird 'not found. Skipping' errors when uninstalling:

https://pastebin.com/6bvZx0ej

Looks like it ignores syswow64 for some reason.

How about implementing a message in the PKGBUILD that would pop up on installation for the user telling them to run setup_dxvk.sh for the actual installation into the wine prefix since the package won't obviously touch it by itself? Thanks.

DXVK upstream just merged d3d8 support, so I updated our setup script. Be sure to re-run it to enjoy DXVK's shiny new d3d8 frontend!

WINEPREFIX="/path/to/your/prefix" setup_dxvk install --symlink

@ssorgatem The package in https://aur.archlinux.org/packages/libdxvk is the linux native version of dxvk, this is the cross-compiled version that produces windows dlls. They are not related in any way except using the same source. Their usage is different, their dependencies are different, they do not even conflict with each other. There is no reason to tie them together.

If you are worried about multiple source tree copies, you should check out SRCDEST env variable in pacman.conf and what it does.