Elizabeth Figura's NTSYNC driver shipped in Linux 6.14. Wine 11 retired esync and fsync over it.

If a Windows game on Linux feels noticeably smoother this spring, the reason has a name. The name is NTSYNC. Linux 6.14 merged it in January, Wine 11 calls it directly, and SteamOS 3.7.20 loads the module by default on every Steam Deck.

The maintainer is Elizabeth Figura at CodeWeavers, who has been pushing the driver up LKML since 2020. After six years of revisions and one near-miss merge for 6.10, the kernel hosts a native implementation of Windows NT’s mutex, semaphore, and event objects. Wine no longer fakes them.

The headline-grabbing benchmarks for NTSYNC are absurd. Dirt 3 jumped from 110 FPS to 860 FPS against an unmodified Wine baseline. Tiny Tina’s Wonderlands tripled. Call of Juarez doubled. Those numbers are real but they’re also a particular flavor of cherry-pick: they compare NTSYNC to upstream Wine without any of the synchronisation patches the gaming distros have shipped for years. The more useful comparison, NTSYNC against the fsync-patched Wine most Steam Deck players were already running, is a single-digit to mid-teens percent speedup with way fewer microstutters. Less photogenic, still real.

The reason it’s a story now, six months after the merge, is that the entire chain of Wine 11, Proton 11, SteamOS 3.7.20, and the mainline kernels every distro is rebasing onto have all landed in roughly the same window. The thing that took years finally tips into “default everywhere.”

What is NTSYNC?

Windows games coordinate threads through a small set of kernel objects: mutexes, semaphores, auto-reset events, manual-reset events, and WaitMultipleObjects. Pretty much every game written since Windows XP uses them, often calling them millions of times per second. Linux’s equivalents are POSIX futexes and eventfd, with semantics that don’t quite line up.

Wine has to bridge the gap. For years, the bridge was wineserver, a userspace process every Wine application talked to over a socket. It worked. It also serialised every synchronisation call through one process, which on a modern CPU is a small disaster.

esync and fsync were the community responses. esync, by Zebediah Figura (Elizabeth’s earlier credit), pushed wait operations into the kernel via eventfd. fsync, by Andrew Eikum at CodeWeavers, did the same trick with futexes. Both produced large speedups. Both also approximated the Windows semantics; some games hit edge cases the patches didn’t model exactly, especially around WaitMultipleObjects returning a specific signaled-object index.

NTSYNC is the real version. The kernel driver exposes a /dev/ntsync character device. Wine CreateMutex allocates an NTSYNC mutex inside the kernel directly. WaitForMultipleObjects becomes a single ioctl that the kernel resolves with the exact NT semantics, including the fairness ordering and the “abandoned mutex” status code. There’s no userspace translation layer left.

Pierre-Loup Griffais, the Valve engineer who oversees SteamOS, put it pretty plainly to Phoronix: “fsync was already fast enough”. He’s right about throughput. But fsync had subtle hitches and deadlocks under certain game patterns, and NTSYNC fixes them. Stability is what Valve was buying.

Why it took six years

Figura’s first patch went out in late 2019. It bounced around LKML for two years getting reshaped by kernel maintainers worried about exposing Windows-shaped primitives to mainline. The argument went something like: “this is a Wine-specific feature; should the kernel host Wine-specific features?”

The eventual answer was yes, with caveats. NTSYNC is a generic synchronisation primitive that happens to express the NT model exactly. Anyone can use it. Wine just happens to be its biggest customer. The driver shipped under drivers/misc/ntsync.c once that framing stuck.

The other delay was that Linux 6.10 nearly merged NTSYNC, then backed out because the API needed reshaping for cross-architecture support. The genuine merge was 6.14. By that point Figura’s patch series was on revision 12.

Who’s using it today

The distro picture is now consistent enough to summarise:

• SteamOS 3.7.20 beta loads the module by default. Stable rollout is staged across the next two SteamOS point releases.
• Ubuntu 25.04 ships kernel 6.14 with the module available; load with modprobe ntsync and Wine 11 picks it up automatically.
• Fedora 42 ships kernel 6.14, module included.
• Debian 13 (testing) picked it up in April; the Debian Wiki has a HowTo for getting Wine 11 to find it.
• Arch / Manjaro / EndeavourOS rolling-released the module within days of the 6.14 release.
• Linux Mint 22 got it via the Edge kernel branch.

If you’re on an LTS kernel older than 6.14 you’ll need to either bump the kernel (Ubuntu’s HWE stack will get you there) or stay on fsync. Wine 11 still includes the fsync path as a fallback; it just doesn’t ship the upstream esync patches anymore.

What this means for you

If you game on Linux: update your kernel to 6.14 or newer, update Wine to 11 (or run any version of Proton 11 or later), and verify lsmod | grep ntsync. Most games will silently get a little smoother. A handful of titles that were genuinely broken on fsync (older Bethesda RPGs and a couple of Ubisoft DRM-protected games) will start working that didn’t.

If you ship a Wine-adjacent product: the userspace performance trick is no longer the moat. CodeWeavers built the primitive, Valve productised it, the rest of the ecosystem inherited it. The differentiation moves up the stack into shader caches, anti-cheat support, and HUD overlays.

If you’re watching Linux on the desktop more broadly: this is the second time in a year that a Windows-shaped primitive got merged for compatibility reasons (the other was the set_robust_list cleanup work). It’s a quiet pattern, but the Steam Deck has now spent two years putting real money behind the argument that “Linux is what we ship the games on.” The kernel is starting to listen.

The bigger pattern

NTSYNC isn’t an isolated import. Wine 11 also picked up a faster path through io_uring for asynchronous file IO, which lets Windows games avoid the userspace queueing that NTFS-on-FUSE used to impose. The futex2 syscall family that landed in 6.7 made it possible to teach the scheduler about owner inheritance, which is the other half of the mutex puzzle (it stops priority-inversion stalls when a high-priority renderer thread waits on a low-priority background loader). Add the set_robust_list cleanup in 6.11 and the picture is consistent: kernel features that exist because Windows games need them on Linux.

The longer arc is more interesting than any single benchmark. Compatibility layers used to be the price of running foreign software. With each of these primitives, the Linux kernel takes ownership of the abstraction itself, which makes the compatibility layer thinner and faster. Wine is in the process of becoming something closer to a syscall translator with a registry editor attached. There’s less and less of it that needs to emulate anything; most of what’s left is policy, paths, and Windows-shaped error codes.

That’s also why this story matters beyond gaming. Every CAD program, audio workstation, or industrial control client that ever ran under Wine inherits the same kernel-level synchronisation. Steinberg’s Cubase 14 demo on Linux, the one Pierre-Loup Griffais demoed at Steam Dev Days last September, is sitting on the same plumbing. The Wine + Proton stack is starting to look like a serious answer for “I have a Windows-only tool and a Linux preference,” not just “I have a Steam library and a Deck.” The kernel work is what makes that credible.

Whether other handheld vendors follow Valve’s lead is the next thing to watch. ASUS’s ROG Ally X has been hedging between Windows and a custom Linux build for two years; Lenovo’s Legion Go S ships with SteamOS now. If the kernel keeps absorbing Windows primitives at this cadence, the cost of choosing Linux for that hardware tier keeps dropping, and the network effect on game compatibility keeps compounding. The Steam Deck made Linux gaming credible; NTSYNC is what makes it normal.