Trying a better DXVK fork

[Grogan]

I noticed that some of my older games had regressed to jumpy behaviour again, despite framerate limiting. I soon learned why, I noticed a commit that removed the DXVK_FRAME_RATE variable. Just yanked it out, and removed it from the readme with no fanfare. I've been busy with other games and haven't been playing any of those, but today was the day it bothered me enough to do something about it.

"Nukes the built-in latency thing (which has only ever really been useful for bringing up Reflex support almost a year ago), and nukes DXVK_FRAME_RATE so that the limiter will now only engage via app profiles or the display mode heuristic, and only if no external limiter is already limiting us to the desired refresh rate (or less).

Users should use mangohud or other external solutions."

What? Remove features and tell people to use third party solutions? It's pretty arrogant too, people started discussions about it and he basically admonished them that it was pointless, and that the options are "NOT" coming back.

Note, however, that it's still possible to limit framerates at the DXGI level in dxvk.conf and conf overrides.

Well... I'm not having that. There's another fork of a fork (netborg-afps) being maintained that incorporates a "low latency thing" and puts back the DXVK_FRAME_RATE var. Also, it brings back the async pipeline, which was removed because it can cause bans with anti-cheat.

dxvk-gplasync-lowlatency
https://github.com/Digger1955/dxvk-gplasync-lowlatency

"GPL" refers to Graphics Pipeline Library (not the GPL license)

More in the readme there, but I'll paste what's important to me

Major changes compared to upstream DXVK

Implemented Low Latency frame pacing mode that aims to greatly reduce latency with minimal impact in fps. Author - netborg-afps

Implemented Asynchronous pipeline compilation (Async) that aims to greatly reduce shader compilation stutter by not blocking the main thread when compiling async pipelines. Authors - jomihaka and Sporif

Implemented the ability to use both (together or separately) Graphics Pipeline Library (GPL) and Asynchronous pipeline compilation (Async) on DXVK 2.1 and later. Author - Ph42oN. Contributor - Britt Yazel

Implemented State Cache for DXVK 2.7 starting from DXVK-GPLALL 2.7-3. Author - Laitinlok

Implemented all of aforementioned in one DXVK package. Author - Digger1955

Provided various GCC (for any OS) builds of DXVK-GPLALL:

a) optimized for SSE2 (-march=x86-64, -mtune=x86-64) CPUs with Link-Time Optimization (LTO, a.k.a. -flto=auto) and -O3 optimization level;

b) optimized for SSE4.2 (-march=x86-64-v2, -mtune=intel) and newer Intel CPUs with Link-Time Optimization (LTO, a.k.a. -flto=auto) and -O3 optimization level.

c) optimized for SSE4.2 (-march=x86-64-v2, -mtune=generic) and newer CPUs with Link-Time Optimization (LTO, a.k.a. -flto=auto) and -O3 optimization level.

The last points don't apply to me because I'm not using binaries, but I use "-march=nehalem -mtune=alderlake" (because AVX subtly breaks) to build DXVK and a release build with meson defaults to -O3 (but this project also seems to be doing it explicitly... warnings from meson "consider using built-in optimization level" lol)

It builds the same way:

Code: Select all

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

Also:

Asynchronous pipeline compilation (Async)

Originally started as hacky solution for shader compilation stutter in dxvk. Similar solution was later added to dxvk itself and promptly removed.

Enabling this solution results in a lot less shader compilation stuttering by not blocking the main thread when compiling async pipelines and (not necessarily) miscellaneous graphical issues while shaders are compiling for the first time.

Asynchronous pipeline compilation is enabled with DXVK_ASYNC=1 environment variable and is equivalent to dxvk.enableAsync = True in dxvk.conf. It is enabled by default.

Asynchronous pipeline compilation is disabled with DXVK_ASYNC=0 environment variable and is equivalent to dxvk.enableAsync = False in dxvk.conf.

This too:

Low Latency frame pacing

Enhances the original dxvk with low-latency frame pacing capabilities to improve game responsiveness and input lag. It also improves latency stability over time, usually resulting in a more accurate playback speed of the generated video.

Low-Latency frame pacing mode aims to reduce latency with minimal impact in fps. Effective when operating in the GPU-limit. Efficient to be used in the CPU-limit as well.

Greatly reduces input lag variations when switching between CPU- and GPU-limit, and compared to the max-frame-latency approach, it has a much more stable input lag when GPU running times change dramatically, which can happen for example when rotating within a scene.

So far, I've just built one to use with Lutris and tried some games that need the DXVK_FRAME_RATE and all is well. For example the Fallout games. Fallout 4 London needs DXVK_FRAME_RATE=60 to behave correctly, where the other Fallout games are good limited to 120. Far Cry 2 also needs 60 FPS, or NPCs will bounce 50 feet in the air lol

I plan to use this DXVK in my next Proton-tkg build (I'm pretty sure I can point it to a pre-built one to roll up with instead of cloning/patching dxvk-master). I could probably also just replace the dlls.

[Grogan]

So yeah, I had a hankering to play F.E.A.R. 2 Project Origin, and with DXVK_FRAME_RATE no longer working, it was glitchy with corpses flopping around spastically, enemies flying through the air when you shoot them and other general symptoms of too high of a frame rate like jumpy game play and bumping into walls and shit all the time.

So I replaced the dlls in the compatibility tool directory (in files/lib64/wine/dxvk and files/lib/wine/dxvk) then switched to another proton and back again so they'd get copied to the wine prefix (that's how the Proton scripts do it, not symlinks). Now the game works correctly again with DXVK_FRAME_RATE=60 %command%

I am otherwise happy with the proton-tkg valve bleeding edge build I did on Dec. 23. so I chose to do it that way. Next build I'll incorporate this fork somehow.

[Grogan]

So I figured out the best way to handle this DXVK fork during my proton-tkg builds. I did a dry run to verify where it copies the dxvk dlls after they are built.

Before the build:

Drop the prebuilt DXVK x32 and x64 directories in wine-tkg-git/proton-tkg/external-resources/dxvk (create the directories if it's the first run) which is where they first go after building with dxvk-tools. That's the real location, the build follows symlinks to that. Then it installs them to proton_dist_tmp/lib64/wine/dxvk (and lib for 32 bit) before finally rolling them up in the compatibility tool's directory (the build results... proton-tkg-blah/files/lib64/wine/dxvk and files/lib/wine/dxvk)

To get it to use those (not clone and build dxvk), in proton-tkg.cfg, I changed _use_dxvk="git" to _use_dxvk="prebuilt"

Note that this is a native proton build though, I'm not so sure you could always get away with just dropping the dlls in when everything is built in Valve's container with their toolchains, against their dev environment (or replacing the dlls in Steam's proton builds, which I did once, but that was years ago). I don't build proton like that.

[Grogan]

Project forks sometimes do unexpected things. I've been unable to build dxvk-gplasync-lowlatency since I upgraded glibc and toolchains on Arch. (For the mingw toolchain, I recompiled it all in dependency order (existing PKGBUILDs), but did not "upgrade" it as I'm unsure of just willy nilly upgrading sources and building them for cross compiling. Itself it's fine, it's just bombing out on this now linking a library). I haven't really had any need to compile it (my last successful build is current) so I didn't get around to looking too deeply into it until today.

With parallel builds and all the ridiculous warnings turned on in modern day, the real source of the build failure is often gone from even my 3000 line terminal buffer. It was linker failures on building DXGI, it was related to LTO objects. What? This project doesn't enable LTO, does it? Not with meson options it doesn't (I tried explicitly adding -Db_lto=false to meson setup in the package-release.sh build script but that's not how it was being done)

So I did a plain jane build, logged to a text file with no CFLAGS/CXXFLAGS and got floods of stupid warnings because it was passing -mtune=x86-64 which is deprecated (use -mtune=generic). Both are pointless in this case, because both -march=x86-64 and -mtune=x86-64 or generic ARE the defaults for the arch if you're not overriding them. I only just noticed that because I always set variables. So I started again with my flags and logged the build so I could see all the compile commands and failures.

Sure enough, it was LTO linking. The project manually added flags to meson.build (dxvk upstream doesn't do this), -flto=auto and -fuse-linker-plugin that goes along with it.

So now I made a little patch for my builds, to remove those silly flags.

no-silly-flags.patch

Code: Select all

--- dxvk-gplasync-lowlatency_orig/meson.build	2026-02-26 19:35:53.367026744 -0500
+++ dxvk-gplasync-lowlatency/meson.build	2026-02-26 19:38:20.973802513 -0500
@@ -12,14 +12,10 @@
 compiler_args = [
   '-O3',
   '-pipe',
-  '-march=x86-64',
-  '-mtune=x86-64',
   '-msse',
   '-msse2',
   '-mfpmath=sse',
   '-fno-semantic-interposition',
-  '-flto=auto',
-  '-fuse-linker-plugin',
   '-Wimplicit-fallthrough',
   # gcc
   '-Wno-missing-field-initializers',