DXVK-Sarek 1.13.0 “Pacemaker” Lands With Major Frame Pacing and Shader Compilation Updates for Legacy Linux Gaming
The unofficial DXVK fork keeping older hardware alive on Linux just got a polished performance release focused on stutter reduction and memory efficiency. DXVK-Sarek 1.13.0, codenamed “Pacemaker,” shipped today and targets the exact user base that upstream DXVK quietly abandoned years ago.
Six years after the original DXVK shipped and pushed Linux gaming past the experimental phase, the toolchain has aged out of support for older silicon. The modern upstream build now requires Vulkan 1.3, which leaves behind Intel Core 2, early Sandy Bridge CPUs, low-end AMD APUs, and ARM SBCs running through Box64. DXVK-Sarek exists to fill that exact gap. Maintained by pythonlover02, the project keeps the Vulkan 1.1 and 1.2-based DXVK 1.10.x codebase alive, backporting fixes and features from modern upstream releases. The previous dedicated Proton-Sarek build has been shelved, with the maintainer citing university and family demands, so the project now ships exclusively through the Proton-CachyOS fork.
What’s Actually New in Pacemaker
The biggest headline is selectable shader compilation. For the first time, you can pick how shaders compile at runtime using the dxvk.shaderCompilationMethod setting or its environment variable equivalent. The new dyasync mode is the default, and pythonlover02 explicitly designed it for weak hardware. It compiles the first shader synchronously, then defers subsequent variants into the background. A previously compiled pipeline acts as a placeholder, swapping in the correct version silently once it finishes. Shader compilation stutters have been a known plague on Linux gaming for years, and most Vulkan layers just throw more threads at the problem. Sarek takes a different route here. Full async mode still exists for beefier systems, but it can starve slower CPUs with an unbounded thread backlog. Raw none mode just mirrors the old 1.10.x behavior and is meant for debugging rendering bugs.
Frame pacing and low-latency mode round out the major feature set. Borrowed from a community project, this addition gives you predictive sleep based on rolling frame averages. low-latency mode is the sweet spot for most setups, while min-latency strips out the prediction for absolute minimum input delay at the cost of visible frame time. You can tune the prediction timing with dxvk.lowLatencyOffset, which accepts values in microseconds. It adapts the original concept to Sarek’s Vulkan 1.1/1.2 presenter, which lacks the telemetry required for VRR-aware pacing.
The frame rate limiter got a complete overhaul as well. Two independent settings now control how each frame’s deadline is calculated and how the limiter waits out the remaining frame time. pythonlover02 specifically recommends the sliced pacing method when running under Box64 or FEX emulation, since the default precise busy-wait tends to fight emulated ARM cores for CPU cycles.
The dynamic memory allocator swaps out the old fixed 128 MiB-per-type chunk system. It starts small, scales up to 256 MiB on demand, and frees empty chunks automatically. Integrated GPU users have been losing games to out-of-memory crashes for a while, and the maintainer notes this change cuts straight through that problem. Given how much system RAM iGPUs typically siphon, that shift alone probably just saved a lot of previously unplayable titles.
D7VK jumped from 1.9 straight to 2.1, landing a major D3D9 bridge rework and legacy lighting fixes credited entirely to @WinterSnowfall. The module is now strictly x86-only, since it never actually functioned on 64-bit or ARM builds. @CkNoSFeRaTU also added D3D9 colorkeying support, which fixes transparency rendering in older titles. The build system dropped its legacy bash scripts in favor of a standard Makefile, and SteamRT container builds now streamline Proton-CachyOS packaging. Several upstream DXVK options like dxvk.hideIntegratedGraphics and dxvk.tilerMode made the cut, alongside new app profiles for Splinter Cell: Double Agent and Astebreed.
It’s a fairly mature release, but that’s exactly the point. Sarek isn’t chasing bleeding-edge APIs anymore. It’s stabilizing a foundation. The selectable shader compilation gives you actual control over the stutter-to-performance tradeoff instead of forcing a single approach. The low-latency mode brings competitive-relevant input timing to hardware that upstream DXVK moved past years ago, though the maintainer warns that both dyasync and async can produce brief visual inaccuracies that client-side anti-cheat might theoretically flag. However, at the same time, the dynamic memory allocator solves a concrete, frequent crash loop for iGPU users. Not exactly flashy. Highly effective.
The only officially supported way to run DXVK-Sarek right now is through Proton-CachyOS. Enable it by setting PROTON_DXVK_SAREK=1 in your environment. Keep in mind that if you also need legacy D3D3 through D3D7 support, you’ll want to throw PROTON_DXVK_SAREK=1 PROTON_D7VK_DDRAW=1 into the mix as well. Standalone users running Lutris, Heroic, or Bottles can manually select DXVK-Sarek as the DXVK version for their Wine prefixes.
Head here to the repo if you’re running an older rig, since the maintainer is actively backporting upstream fixes.
