DXVK-Sarek 1.14.0 Gives Older GPUs a Second Life for Windows Games on Linux
The unofficial 1.10.x fork now reports exactly which Vulkan features it's faking, and finally kills the memory-leak crashes that have plagued long play sessions for years.
There's a niche corner of Linux gaming that the headline launches almost never cover: coaxing Windows Direct3D titles out of hardware that upstream DXVK has quietly given up on. As of October 8, that corner just got a real update. DXVK-Sarek 1.14.0 shipped today, marking the most substantial change to the project's 1.10.x branch in a while.
You need a quick refresher on DXVK to see why it matters. Philip Rebohle, who runs online as doitsujin, built the mainline tool to translate Microsoft's Direct3D into Vulkan, the API your GPU already speaks natively. Without that translation, a huge back-catalog of older 3D games simply won't run on Linux, macOS, or Android. The mainline repo is a behemoth now, sitting at roughly 18,200 GitHub stars. Sarek is a cozy 385 stars by comparison. Small numbers. But that smallness is kind of the point.
The people the mainline project stopped serving are exactly why Sarek exists. Picture older GPUs whose Vulkan drivers got abandoned, shipped incomplete, or never gained a few extensions. With the latest official DXVK, a single missing extension is a hard crash before the game even launches. Sarek treats almost every extension as optional instead.
That choice defines the whole project. A missing capability doesn't bail out anymore. It produces what the author calls a "degraded" device. The game still runs, though you may end up with wrong colors, missing geometry, or objects floating where they shouldn't. Until 1.14.0, that degradation was mostly a mystery. The new log now spells it out right after device creation.
The release notes describe it plainly. Sarek lists which extensions are missing and what each gap looks like on screen; geometry stretched past the near plane, or particles and skinned models that just vanish. If nothing's wrong, the log prints degraded features: none. Flip on the on-screen HUD with DXVK_HUD=devinfo and you get a [DEGRADED] tag stamped onto the device line, which helps if you're filing a bug or just want to flag odd rendering in a screenshot.
Head here to the release page for the raw log format. It's genuinely handy for troubleshooting, and it forces a kind of honesty that mainline DXVK doesn't really bother with.
The memory rework was the big one
The change most people will actually feel is the memory system. Old chunk allocators let VRAM usage creep up over long sessions, and that creep eventually ended in out-of-memory crashes. 1.14.0 swaps in the page and pool allocators from upstream, which is the fix people had been waiting on for a while. The author cites a pile of reports as the bugs getting squashed.
Alongside that, the memory HUD now shows usage relative to your heap budget, so you actually have context for the numbers. Defragmentation isn't supported yet. The author is coy about whether it'll ever land, given how buggy it's proven on drivers it was never meant to run on.
Memory isn't the only story. Contributor @WinterSnowfall backported D7VK v2.2 for better Direct3D 7 coverage and enabled per-stage color keying. There's also a fix for the classic black screen on macOS MoltenVK, where D3D9 samplers ask Metal to do something it can't express. You get a new d3d9.splitSamplerSlots option to toggle it, with Auto, True, and False states, in an independent reimplementation of a fix originally by @MiloszP.
The rest is a pile of smaller correctness fixes: garbled text in Civilization VI, a DXGI change so fullscreen games bail out cleanly when you switch away, an out-of-bounds selection bug in dxbc, and a guard against a zero refresh-rate denominator. It adds up.
Proton-Sarek is gone, and the hardware it serves isn't
One thing worth flagging: Proton-Sarek, the sibling project that packaged this for Proton, has been officially discontinued. pythonlover02 says juggling university, a job, family duties, and two open-source projects wasn't sustainable. He says he's on good terms with the CachyOS Proton developer, the one who'd already integrated Sarek because he personally owns the kind of hardware that needs it.
So as of now, Proton-CachyOS with PROTON_DXVK_SAREK=1 is the only officially supported way to run Sarek under Proton. The author stays focused on DXVK-Sarek itself and a couple of side projects, and stays open to shipping it in Valve's or Garden Engine's Proton builds too. It's a pragmatic pivot, and honestly a sensible one. CachyOS is one of the few distros still shipping older drivers like nvidia-470, which is the exact audience here. The project even targets ARM emulation, mobile GPUs, and macOS, a wider net than most people expect from a DXVK fork.
The extras beyond 1.14.0
The build carries a few advanced options on top of the release itself, worth knowing about if you're tuning an old machine. You can pick between three shader compilation methods: the default dyasync defers shader variants to background threads after an initial compile, the fully async mode removes stalls but can starve weak CPUs, and none reverts to classic 1.10.x behavior as a debugging reference. There's also a frame-pacing mode adapted from the dxvk-low-latency project for trading input lag against performance, plus fine-grained frame-rate limiting with several pacing methods. All of it is optional.
Getting it running
To run Sarek you need a Vulkan 1.1-capable GPU and driver, plus Wine 7.1 or newer (or Proton-CachyOS with the flag). Both 32-bit and 64-bit DLLs ship, set up just like mainline DXVK.
The easy route is a launcher. Lutris and Heroic let you pick Sarek directly, and ProtonPlus and ProtonUpQT (Flathub) will add it if your launcher doesn't list it. For the DIY crowd, clone and build with the usual recursive clone-and-make dance against the GitHub repo.
It's not for everyone. This is a targeted, community-driven build aimed squarely at a shrinking slice of hardware, and a degraded feature can still mean a game just won't look right. But for the players mainstream DXVK moved past, it's a real quality-of-life gain. As pythonlover02 frames it, "your hardware is too old for DXVK" shouldn't mean you're out of the game.
Head here to the GitHub release page.
