Note

Development may be slow at times, but this project is still maintained even if the last commit was made a while ago.

DXVK-Sarek:

Why Does This Repo Exist?

This repository was created to support users with Vulkan capable GPUs that do not meet the 1.3 requirement of the current builds. My goal is to ensure that everyone can benefit from the nice performance of DXVK, even if their hardware is slightly older. Creating or backporting Quality of Life (QOL) patches, fixes and per game configurations from the latest versions to the 1.10.x branch.

This project is supported on proton-cachyos, on this you must add this env var to your launch options:

PROTON_DXVK_SAREK=1

Also, a huge thank you to the following contributors for their invaluable help in making this project a reality:

• Blisto91
• AmerXz
• Gcenx
• WinterSnowfall

Your contributions are greatly appreciated!

Full credit goes to doitsujin/ドイツ人 (Philip Rebohle) and everyone that have worked on the dxvk project. You can find the original DXVK repository here: dxvk.

---

---

How to Use

Please follow the official guide from the upstream DXVK README.

Keep in mind that this is a manual installation method, which isn’t the most convenient. An easier approach is to use a Linux game launcher such as Lutris, Heroic, or similar. There you can simply select DXVK-Sarek as the DXVK version (for Wine) or Proton-Sarek (for Proton).

If they’re not available by default, you can easily install them using ProtonPlus and ProtonUpQT.

Build instructions

In order to pull in all submodules that are needed for building, clone the repository using the following command/commands:

For Normal DXVK:

git clone --branch main --recurse https://github.com/pythonlover02/DXVK-Sarek.git DXVK

For DXVK with Async Patch:

git clone --branch async --recurse https://github.com/pythonlover02/DXVK-Sarek.git DXVK-Async

Requirements:

• wine 7.1 or newer
• Meson build system (at least version 0.49)
• Mingw-w64 compiler and headers (at least version 10.0)
• glslang compiler

Building DLLs

The simple way

Inside the DXVK directory, run:

./package-release.sh master /your/target/directory --no-package

This will create a folder dxvk-master in /your/target/directory, which contains both 32-bit and 64-bit versions of DXVK, which can be set up in the same way as the release versions as noted above.

In order to preserve the build directories for development, pass --dev-build to the script. This option implies --no-package. After making changes to the source code, you can then do the following to rebuild DXVK:

# change to build.32 for 32-bit
cd /your/target/directory/build.64
ninja install

Compiling manually

# 64-bit build. For 32-bit builds, replace
# build-win64.txt with build-win32.txt
meson setup --cross-file build-win64.txt --buildtype release --prefix /your/dxvk/directory build.w64
cd build.w64
ninja install

The D3D9, D3D10, D3D11 and DXGI DLLs will be located in /your/dxvk/directory/bin. Setup has to be done manually in this case.

Logs

When used with Wine, DXVK will print log messages to stderr. Additionally, standalone log files can optionally be generated by setting the DXVK_LOG_PATH variable, where log files in the given directory will be called app_d3d11.log, app_dxgi.log etc., where app is the name of the game executable.

On Windows, log files will be created in the game's working directory by default, which is usually next to the game executable.

HUD

The DXVK_HUD environment variable controls a HUD which can display the framerate and some stat counters. It accepts a comma-separated list of the following options:

• devinfo: Displays the name of the GPU and the driver version.
• fps: Shows the current frame rate.
• frametimes: Shows a frame time graph.
• submissions: Shows the number of command buffers submitted per frame.
• drawcalls: Shows the number of draw calls and render passes per frame.
• pipelines: Shows the total number of graphics and compute pipelines.
• memory: Shows the amount of device memory allocated and used.
• gpuload: Shows estimated GPU load. May be inaccurate.
• version: Shows DXVK version.
• api: Shows the D3D feature level used by the application.
• cs: Shows worker thread statistics.
• compiler: Shows shader compiler activity
• samplers: Shows the current number of sampler pairs used [D3D9 Only]
• scale=x: Scales the HUD by a factor of x (e.g. 1.5)
• opacity=y: Adjusts the HUD opacity by a factor of y (e.g. 0.5, 1.0 being fully opaque).

Additionally, DXVK_HUD=1 has the same effect as DXVK_HUD=devinfo,fps, and DXVK_HUD=full enables all available HUD elements.

Frame rate limit

The DXVK_FRAME_RATE environment variable can be used to limit the frame rate. A value of 0 uncaps the frame rate, while any positive value will limit rendering to the given number of frames per second. Alternatively, the configuration file can be used.

Device filter

Some applications do not provide a method to select a different GPU. In that case, DXVK can be forced to use a given device:

• DXVK_FILTER_DEVICE_NAME="Device Name" Selects devices with a matching Vulkan device name, which can be retrieved with tools such as vulkaninfo. Matches on substrings, so "VEGA" or "AMD RADV VEGA10" is supported if the full device name is "AMD RADV VEGA10 (LLVM 9.0.0)", for example. If the substring matches more than one device, the first device matched will be used.

Note: If the device filter is configured incorrectly, it may filter out all devices and applications will be unable to create a D3D device.

State cache

DXVK caches pipeline state by default, so that shaders can be recompiled ahead of time on subsequent runs of an application, even if the driver's own shader cache got invalidated in the meantime. This cache is enabled by default, and generally reduces stuttering.

The following environment variables can be used to control the cache:

• DXVK_STATE_CACHE=0 Disables the state cache.
• DXVK_STATE_CACHE_PATH=/some/directory Specifies a directory where to put the cache files. Defaults to the current working directory of the application.

Shader compilation

DXVK-Sarek includes dyasync (Dynamic Asynchronous Pipeline Compilation), enabled by default.

When a shader is encountered for the very first time, it must be compiled synchronously, this is unavoidable and may cause a brief stutter. However, every variant after that is handled differently. A variant is created whenever the game uses the same shaders with a different combination of fixed-function state (blend mode, depth test, cull mode, render pass, etc.), each unique combination counts as a new variant.

When a new variant is needed, dyasync does not stall the game to compile it. Instead, it grabs the closest already compiled pipeline for those same shaders (perhaps one compiled with different blend settings) and uses it as a placeholder while the correct variant builds in a background thread. Once the background compilation finishes, it silently swaps in the correct pipeline. This reduces stuttering and improves frametimes.

This approach is safer than the traditional async patch because something valid is always being rendered on screen, there are no invisible or missing objects. That said, during the brief placeholder period, minor visual inaccuracies are possible (e.g. slightly wrong blending). Use in multiplayer games at your own discretion.

Dyasync can be disabled by setting dxvk.enableDyasync = False in dxvk.conf, in the DXVK_CONFIG environment variable, or by using the environment variable DXVK_DISABLE_DYASYNC=1.

• DXVK_ALL_CORES=1 When this env var is used, it overwrites the default way we assign cores to compile shaders. By default, DXVK-Sarek uses roughly half the available CPU cores for background compilation, leaving the rest free for the game. On CPUs with weak per core performance that rely on all cores for good throughput, this may cause longer loading times. When DXVK_ALL_CORES=1 is set, all available cores are used for both the game and shader compilation. This may cause brief unresponsiveness while compiling shaders but can improve the overall experience on such hardware.

Debugging

The following environment variables can be used for debugging purposes.

• VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation Enables Vulkan debug layers. Highly recommended for troubleshooting rendering issues and driver crashes. Requires the Vulkan SDK to be installed on the host system.
• DXVK_LOG_LEVEL=none|error|warn|info|debug Controls message logging.
• DXVK_LOG_PATH=/some/directory Changes path where log files are stored. Set to none to disable log file creation entirely, without disabling logging.
• DXVK_CONFIG_FILE=/xxx/dxvk.conf Sets path to the configuration file.
• DXVK_CONFIG="dxgi.hideAmdGpu = True; dxgi.syncInterval = 0" Can be used to set config variables through the environment instead of a configuration file using the same syntax. ; is used as a seperator.
• DXVK_PERF_EVENTS=1 Enables use of the VK_EXT_debug_utils extension for translating performance event markers.

Troubleshooting

DXVK requires threading support from your mingw-w64 build environment. If you are missing this, you may see "error: ‘std::cv_status’ has not been declared" or similar threading related errors.

On Debian and Ubuntu, this can be resolved by using the posix alternate, which supports threading. For example, choose the posix alternate from these commands:

update-alternatives --config x86_64-w64-mingw32-gcc
update-alternatives --config x86_64-w64-mingw32-g++
update-alternatives --config i686-w64-mingw32-gcc
update-alternatives --config i686-w64-mingw32-g++

For non debian based distros, make sure that your mingw-w64-gcc cross compiler does have --enable-threads=posix enabled during configure. If your distro does ship its mingw-w64-gcc binary with --enable-threads=win32 you might have to recompile locally or open a bug at your distro's bugtracker to ask for it.