DXVK-Sarek 1.14.1 lands with a single fix for a fork that keeps old GPUs in the game
The latest patch closes a d3d10core crash that killed every D3D10 title, riding along on the feature-rich 1.14.0 release that brought aging hardware back to life.
DXVK-Sarek 1.14.1 landed today, and it does exactly one thing. It fixes d3d10core crashing every d3d10 game. Small fix, sure. But this is the fork that keeps old GPUs alive, so even a single patch lands with a bit more weight than usual.
Most of the biggest PC games still build on Direct3D, and Direct3D only runs on Windows. Boot those games on Linux through Wine or Valve's Proton fork, and something has to stand in for the missing graphics API or the game just won't start. That something is DXVK, which translates Windows DirectX calls into Vulkan at runtime. It's arguably the single most important piece of the Linux gaming puzzle. Upstream, though, it has steadily raised the floor for what hardware qualifies.
The current 2.x line of DXVK effectively requires Vulkan 1.3 now. That leaves a real crowd behind. Older pre-RTX cards, AMD and NVIDIA chips, GPUs stuck on NVIDIA's long-lived 470.xx driver line. On those systems, current DXVK simply refuses to create a graphics device. Games crash on startup with an "A D3D11-compatible GPU is required" message, and you're politely told to buy new hardware.
DXVK-Sarek is the counterargument. It's an unofficial fork that keeps the old DXVK 1.10.x branch alive, maintained by a part-time developer who goes by pythonlover02. The whole point, in the maintainer's own words, is that "your hardware is too old for DXVK" shouldn't mean you're out of the game.
One fix, but the story is bigger
DXVK-Sarek 1.14.1 is commit 0c0e8f6, and the fix is PR #83, contributed by @The412Banner. The d3d10core profile is a subset variant of DX10 that certain engines and anti-cheat systems target. Before this patch, any game launched through that entry point crashed on startup. After it, those games can create a device and actually run.
The fix is narrow. Understanding why it matters means looking at what 1.14.0 built on. That release came out three days earlier, on 9 October, and it's where the interesting stuff lives.
Its headline move is a "Degraded Features" system. Almost every Vulkan extension DXVK relies on is now marked optional. If your hardware is missing one, device creation no longer fails loudly. Instead the game runs, and the missing feature shows up as a rendering glitch. Wrong colors. Missing geometry. Instanced objects floating in the wrong spot. The log tells you exactly which extension is missing and how it looks on screen, and you can stamp [DEGRADED] onto your HUD with DXVK_HUD=devinfo if you want proof in a screenshot. Sarek would rather run your game with visible glitches than refuse to launch, and then make sure you notice the glitches.
There's an inverse switch too. Strict mode, set with DXVK_SAREK_STRICT=1, makes every optional extension required so device creation fails again and names each missing piece. It's meant purely for debugging, to tell a driver gap from a Sarek bug. If a game won't start in strict mode, the missing extensions are on your driver, not in Sarek.
The 1.14.0 batch also rewrote the memory allocator, swapping the old chunk approach for page and pool allocators. That's meant to fix memory creep during long sessions and the recurring out-of-memory crashes that plagued extended play. A windowing rework takes on some alt-tab issues and makes future WSI fixes easier to backport. A D7VK v2.2 backport strengthens Direct3D 3 through 7 support, and there's a macOS fix for D3D9 black screens under MoltenVK.
Sarek also defaults to dyasync, a shader-compilation trick that compiles the first shader it sees, then defers later variants by drawing the closest finished pipeline as a placeholder while the real one builds in the background. On weak CPUs, which is exactly Sarek's target, that holds higher frame rates than older methods because objects never go invisible. The maintainer does warn that shuffling shader compilation this way could theoretically get caught by anti-cheat in multiplayer games, so use that one at your own discretion.
What you actually need
To run Sarek today, you need a Vulkan 1.1-capable GPU and driver, plus Wine 7.1 or newer, or Proton-CachyOS with the PROTON_DXVK_SAREK=1 environment variable. Both 32-bit and 64-bit DLLs ship the same way as upstream DXVK. Drop them into a game's prefix via a launcher, or patch them into a Proton build by hand.
Proton-CachyOS is currently the only officially supported path, using PROTON_DXVK_SAREK=1 (throw in PROTON_D7VK_DDRAW=1 too if you want the D3D3-7 support). It also installs manually into Valve's Proton, Proton-GE, or plain Wine. Launchers like Lutris and Heroic let you select DXVK-Sarek as the DXVK version. CachyOS makes sense here since it's one of the few distros that still officially offers old drivers like nvidia-470.
Is it worth it? Not for everyone. If you have modern hardware, upstream DXVK is the way to go. But if you've got an older card sitting around and a game that won't start, Sarek will at least get it running, glitches and all. The transparency is the selling point: rather than hide limitations, it shows you exactly what's broken and lets you decide. For what it's worth, that's a respect-for-the-user approach you don't see much in this space.
Head here to the GitHub release page to grab 1.14.1.
