Commissioned, curated and published by Russ. Researched and written with AI.
What’s New This Week
Wine 11.0 shipped in January 2026 with NTSYNC support, and as of March 2026 Valve has already added the NTSYNC kernel driver to SteamOS 3.7.20 beta with the module loaded by default. The unofficial Proton GE fork already enables it. When official Proton rebases on Wine 11, every Steam Deck owner gets this automatically.
Changelog
| Date | Summary |
|---|---|
| 24 Mar 2026 | Initial publication. |
Dirt 3 went from 110.6 FPS to 860.7 FPS. That’s the number that’s been circulating since the NTSYNC developer benchmarks appeared on LWN. Call of Juarez went from 99.8 to 224.1 FPS. Tiny Tina’s Wonderlands from 130 to 360 FPS. Resident Evil 2 from 26 to 77 FPS.
Before you forward this to your Linux gaming friends: these benchmarks compare NTSYNC against vanilla upstream Wine with neither fsync nor esync enabled. Most Proton users already have fsync, so the real-world improvement from migrating to NTSYNC is meaningful but more modest than these headline numbers suggest. The gains for stock Wine users are dramatic. For Proton users, they’re incremental but real – and critically, NTSYNC is semantically correct in ways that fsync never was.
That distinction matters. NTSYNC isn’t just a faster workaround. It’s the first time Wine’s synchronisation has been correct at the kernel level. That’s the actual story.
The Problem: Multi-threaded Games and the Wineserver Bottleneck
Modern Windows games are heavily multi-threaded. Rendering, physics, asset streaming, audio, and AI are running concurrently across multiple threads, and those threads coordinate through what the Windows NT kernel calls synchronisation primitives – mutexes, semaphores, events, wait-for-all operations. These aren’t optional abstractions. Games call them thousands of times per second.
Linux doesn’t have native equivalents that behave exactly like NT synchronisation objects. Wine has historically emulated them, and the original approach was genuinely slow: every synchronisation call required a round-trip RPC to a dedicated wineserver process. For a game hammering these calls at high frequency, the overhead accumulated into frame stutters, inconsistent frame pacing, and a general sense that something was wrong even when average FPS looked acceptable.
The Solution Ladder: Esync, Fsync, and Why Neither Was Enough
Two workarounds emerged before NTSYNC. Elizabeth Figura at CodeWeavers developed esync first, using Linux’s eventfd system call to handle synchronisation without bouncing through the wineserver. It helped substantially, but every synchronisation object required its own file descriptor – and games that opened many of them hit system-level descriptor limits.
Fsync followed, using futexes for better performance. Faster than esync in most cases, but it required out-of-tree kernel patches that never made mainline. You needed a custom or patched kernel to use it, which was fine for enthusiasts on CachyOS or running Proton-GE, but inaccessible for anyone on stock Ubuntu or Fedora. The situation with futex variants is also genuinely confusing: Futex2 (futex_waitv) made it into kernel 5.16, but the original fsync used futex_wait_multiple, which is different. Applications like Lutris still call it fsync regardless.
Both approaches shared a deeper problem: they approximated NT synchronisation semantics using Linux primitives that weren’t designed for the job. Operations like NtPulseEvent() and the wait-for-all mode in NtWaitForMultipleObjects() require direct control over underlying wait queues in ways that userspace implementations can’t reliably provide. You could get close. You couldn’t get correct.
What NTSYNC Actually Does
NTSYNC takes the only approach that can actually solve the problem: add the semantics to the kernel.
A kernel driver now exposes a /dev/ntsync device that directly models the Windows NT synchronisation object API. Wine talks to the driver, and the kernel handles the coordination. No wineserver round-trips. No approximation. Proper queue management, proper event semantics, proper atomic operations – because the kernel has the authority to implement them correctly.
What makes this particularly notable is that Elizabeth Figura built it – the same engineer who wrote esync and fsync. She spent years iterating on the kernel patch set, presented the work at Linux Plumbers Conference in 2023, and pushed through multiple versions before it was finally merged into the mainline kernel with version 6.14. This isn’t a quick hack that landed upstream through community enthusiasm. It’s the result of years of work by someone who understood the problem space better than anyone.
NTSYNC is now in the mainline kernel as of 6.14, which means no custom patches, no out-of-tree modules, no special kernel builds. Any distro shipping kernel 6.14 or later – Fedora 42, Ubuntu 25.04, and newer releases – has it available. The kernel docs cover the userspace API at docs.kernel.org/userspace-api/ntsync.html.
The Benchmark Numbers in Context
The developer benchmarks from LWN show dramatic numbers because they’re comparing against the worst case: vanilla upstream Wine with none of the userspace workarounds enabled. If you’ve been running Proton with fsync, your baseline is already much better, and the marginal gain from NTSYNC over fsync is more modest.
That said, there are categories of games where NTSYNC delivers improvements that fsync couldn’t. Titles with heavy multi-threaded workloads were where fsync’s approximation limitations showed up most clearly – edge cases in NtPulseEvent() and similar primitives that the userspace implementations couldn’t handle correctly. For those games, NTSYNC isn’t just faster, it’s correct where fsync was subtly broken. Call of Duty: Black Ops I reportedly moved from unplayable to playable under NTSYNC, which is a qualitative shift, not just a performance delta.
The broad applicability also matters. Because NTSYNC is mainline, it becomes the default path for all Wine users on modern kernels – not just enthusiasts who know to opt into Proton-GE or CachyOS.
WoW64 Completion: The Other Major Change
If NTSYNC is the headline, the WoW64 overhaul is the change that will affect everyday usability for years.
Wine 11 completes the multi-year effort to implement proper 32-bit-on-64-bit support internally. The practical result: Wine no longer requires 32-bit system libraries installed on your 64-bit host to run 32-bit Windows applications. There’s now a single wine binary. It handles the detection and translation internally. The wine32 and wine64 commands are gone.
This matters for gaming because a substantial number of older games ship as 32-bit executables, and getting them to work previously meant wrestling with your distro’s multilib setup – quality and ease varying significantly between Ubuntu, Arch, Fedora, and everything else. That problem is now Wine’s problem, not yours.
The WoW64 mode also covers OpenGL memory mappings, SCSI pass-through, and even 16-bit application support. The 16-bit case is mostly an edge case for legacy software archaeology, but it demonstrates the completeness of the implementation. On the OpenGL side, there’s related work happening in Mesa – a new MESA_map_buffer_client_pointer extension addresses the problem of 64-bit GPU buffer addresses being unreachable by 32-bit code, with Wine explicitly driving that development.
For distros that have dropped 32-bit library support entirely – openSUSE Leap 16, and macOS has been there since Catalina – Wine 11 becomes usable where previous versions simply weren’t.
Wayland, Vulkan, and the Rest
Wayland support has grown up considerably. Clipboard operations now work bidirectionally between Wine and native Wayland applications. Drag-and-drop from Wayland apps into Wine windows works. Display mode switching is now handled through compositor scaling rather than actual mode changes, which means old games requesting 640x480 behave correctly instead of breaking the compositor state.
On the graphics stack: EGL replaces GLX as the default OpenGL backend on X11. Vulkan support advances to API version 1.4. Hardware-accelerated H.264 decoding arrives through Direct3D 11 video APIs using Vulkan Video – relevant for games that use video playback for cutscenes or in-game streaming.
Thread priority management has been improved on both Linux and macOS, which contributes to multi-threaded performance beyond the NTSYNC gains. ARM64 can now simulate 4K page sizes on systems with larger native pages, which keeps Wine viable on the growing range of ARM Linux hardware.
Specific compatibility fixes landed for Nioh 2, StarCraft 2, The Witcher 2, Call of Duty: Black Ops II, Final Fantasy XI, and Battle.net. Plus several hundred smaller bug fixes.
The Proton and SteamOS Implications
Everything built on top of Wine – Proton, Lutris, Bottles, CrossOver – inherits these changes when it rebases. Valve has already integrated the NTSYNC kernel driver into SteamOS 3.7.20 beta with the module loaded by default. Proton GE already enables it. When official Proton rebases on Wine 11, the improvement reaches every Steam Deck automatically, without any user action.
Valve’s investment in SteamOS has been the forcing function for Wine’s pace of improvement over the past several years. NTSYNC’s multi-year journey to the mainline kernel was driven in significant part by the commercial reality that Valve needed it for SteamOS to compete on performance. The Register has noted that NTSYNC represents a fairly unusual addition to the Linux kernel – it provides no benefit to native Linux programs. It exists purely to improve Windows binary performance under Wine. That kind of narrow, commercially-motivated kernel addition getting merged into mainline is a testament to how seriously Valve’s Linux investment is being taken by the kernel community.
What This Changes
The benchmark numbers are real, with the important caveat about baseline. But the more significant shift is structural: Linux gaming is no longer compensating for a fundamental synchronisation deficit. The NT synchronisation model is now in the kernel. Games that were genuinely broken on Linux due to synchronisation edge cases have a path to working correctly, not just working adequately.
The WoW64 completion means the 32-bit library mess that has frustrated Wine users for years is gone. A single binary handles 32-bit and 64-bit Windows executables on a 64-bit Linux system, no multilib gymnastics required.
Valve’s early adoption of NTSYNC in SteamOS beta is a signal. When official Proton picks this up – and it will – the Steam Deck gets a meaningful performance and compatibility improvement without any hardware change. For engineers running Linux as their primary development environment who also want to game without dual-booting, the friction just dropped again.
The received wisdom that Linux gaming is fundamentally slower than Windows is wearing thin. It was always more nuanced than that – the gap was concentrated in specific workloads and specific failure modes. NTSYNC eliminates one of the real ones.