Wine 11 rewrites how Linux runs Windows games at kernel with massive speed gains
Recorded: March 25, 2026, 3 a.m.
| Original | Summarized |
Wine 11 rewrites how Linux runs Windows games at the kernel level, and the speed gains are massive Menu Sign in now Close News Tech Deals PC Hardware Submenu CPU GPU Storage Monitors Keyboards & Mice Software Productivity Self-Hosting Home Lab Other Software Operating Systems Windows Linux macOS Devices Submenu Single-Board Computers Laptops Gaming Handheld Prebuilt PC Home Networking Smart Home Entertainment Submenu Entertainment Gaming Sign in Newsletter Menu Follow Followed Like Threads More Action Sign in now 🔥Tech Deals ESP32 Windows 11 NotebookLM Gaming Forums Close Wine 11 rewrites how Linux runs Windows games at the kernel level, and the speed gains are massive By Published Mar 23, 2026, 12:31 PM EDT I’m Adam Conway, an Irish technology fanatic with a BSc in Computer Science and I'm XDA’s Lead Technical Editor. My Bachelor’s thesis was conducted on the viability of benchmarking the non-functional elements of Android apps and smartphones such as performance, and I’ve been working in the tech industry in some way or another since 2017. In my spare time, you’ll probably find me playing Counter-Strike or VALORANT, and you can reach out to me at adam@xda-developers.com, on Twitter as @AdamConwayIE, on Instagram as adamc.99, or u/AdamConwayIE on Reddit. Sign in to your XDA account Add Us On follow Follow followed Followed Like Like Thread Log in Here is a fact-based summary of the story contents: Try something different: Show me the facts Explain it like I’m 5 Give me a lighthearted recap Linux gaming has come a long way. When Valve launched Proton back in 2018, it felt like a turning point, turning the Linux gaming experience from "technically possible if you're okay with a lot of pain" to something that more or less worked. Since then, we've seen incremental Wine releases, each one chipping away at compatibility issues and improving performance bit by bit. Wine 10, Wine 9, and so on; each one a collection of bug fixes and small improvements that kept the ecosystem moving forward. Wine 11 is different. This isn't just another yearly release with a few hundred bug fixes and some compatibility tweaks. It represents a huge number of changes and bug fixes. However, it also ships with NTSYNC support, which is a feature that has been years in the making and rewrites how Wine handles one of the most performance-sensitive operations in modern gaming. On top of that, the WoW64 architecture overhaul is finally complete, the Wayland driver has grown up a lot, and there's a big list of smaller improvements that collectively make this feel like an all-new project. I should be clear: not every game is going to see a night-and-day difference. Some titles will run identically to before. But for the games that do benefit from these changes, the improvements range from noticeable to absurd. And because Proton, SteamOS, and every downstream project builds on top of Wine, those gains trickle down to everyone. Esync and fsync worked, but they weren't ideal If you've spent any time tweaking Wine or Proton settings, you've probably encountered the terms "esync" and "fsync" before. Maybe you toggled them on in Lutris, or noticed them in Proton launch options, without fully understanding what they do. To understand why NTSYNC matters, you need to understand the problem these solutions were all trying to solve. Windows games, especially modern ones, are heavily multi-threaded. Your CPU isn't just running one thing at a time, and instead, it's juggling rendering, physics calculations, asset streaming, audio processing, AI routines, and more, all in parallel across multiple threads. These threads need to coordinate with each other constantly. One thread might need to wait for another to finish loading a texture before it can render a frame. Another might need exclusive access to a shared resource so two threads don't try to modify it simultaneously. Windows handles this coordination through what are called NT synchronization primitives... mutexes, semaphores, events, and the like. They're baked deep into the Windows kernel, and games rely on them heavily. The problem is that Linux doesn't have native equivalents that behave exactly the same way. Wine has historically had to emulate these synchronization mechanisms, and the way it did so was, to put it simply, not ideal. The original approach involved making a round-trip RPC call to a dedicated "kernel" process called wineserver every single time a game needed to synchronize between threads. For a game making thousands of these calls per second, that overhead added up fast and served to be a bottleneck. And it was a bottleneck that manifested as subtle frame stutters, inconsistent frame pacing, and games that just felt a little bit off even when the raw FPS numbers looked fine. Esync was the first attempt at a workaround. Developed by Elizabeth Figura at CodeWeavers, it used Linux's eventfd system call to handle synchronization without bouncing through the wineserver. It worked, and it helped, but it had quirks. Some distros ran into issues with file descriptor limits, since every synchronization object needed its own file descriptor, and games that opened a lot of them could hit the system's ceiling quite quickly. Fsync came next, using Linux futexes for even better performance. It was faster than esync in most cases, but it required out-of-tree kernel patches that never made it into the mainline Linux kernel or to upstream Wine out of the box. That meant you needed a custom or patched kernel to use it, which is fine for enthusiasts running CachyOS or Proton-GE, but not exactly accessible for the average user on Ubuntu or Fedora. Futex2, often referred to interchangeably with fsync, did make it to Linux kernel 5.16 as futex_waitv, but the original implementation of fsync isn't that. Fsync used futex_wait_multiple, and Futex2 used futex_waitv. Applications such as Lutris still refer to it as Fsync, though. It's still kind of fsync, but it's not the original fsync. Here's the thing about both esync and fsync: they were workarounds. Clever ones, but workarounds nonetheless. They approximated NT synchronization behavior using Linux primitives that weren't designed for the job, and certain edge cases simply couldn't be handled correctly. Operations like NtPulseEvent() and the "wait-for-all" mode in NtWaitForMultipleObjects() require direct control over the underlying wait queues in ways that user-space implementations just can't reliably provide. Synchronization at the kernel-level, rather than in user-space NTSYNC takes a completely different approach. Instead of trying to shoehorn Windows synchronization behavior into existing Linux primitives, it adds a new kernel driver that directly models the Windows NT synchronization object API. It exposes a /dev/ntsync device that Wine can talk to, and the kernel itself handles the coordination. No more round trips to wineserver, no more approximations, and the synchronization happens in the kernel, which is where it should be. And it has proper queue management, proper event semantics, and proper atomic operations. What makes this even better is that NTSYNC was developed by the same person who created esync and fsync in the first place. Elizabeth Figura has been working on this problem for years, iterating through multiple kernel patch revisions, presenting the work at the Linux Plumbers Conference in 2023, and pushing through multiple versions of the patch set before it was finally merged into the mainline Linux kernel with version 6.14. The numbers are wild. In developer benchmarks, Dirt 3 went from 110.6 FPS to 860.7 FPS, which is an impressive 678% improvement. Resident Evil 2 jumped from 26 FPS to 77 FPS. Call of Juarez went from 99.8 FPS to 224.1 FPS. Tiny Tina's Wonderlands saw gains from 130 FPS to 360 FPS. As well, Call of Duty: Black Ops I is now actually playable on Linux, too. Those benchmarks compare Wine NTSYNC against upstream vanilla Wine, which means there's no fsync or esync either. Gamers who use fsync are not going to see such a leap in performance in most games. The games that benefit most from NTSYNC are the ones that were struggling before, such as titles with heavy multi-threaded workloads where the synchronization overhead was a genuine bottleneck. For those games, the difference is night and day. And unlike fsync, NTSYNC is in the mainline kernel, meaning you don't need any custom patches or out-of-tree modules for it work. Any distro shipping kernel 6.14 or later, which at this point includes Fedora 42, Ubuntu 25.04, and more recent releases, will support it. Valve has already added the NTSYNC kernel driver to SteamOS 3.7.20 beta, loading the module by default, and an unofficial Proton fork, Proton GE, already has it enabled. When Valve's official Proton rebases on Wine 11, every Steam Deck owner gets this for free. All of this is what makes NTSYNC such a big deal, as it's not simply a run-of-the-mill performance patch. Instead, it's something much bigger: this is the first time Wine's synchronization has been correct at the kernel level, implemented in the mainline Linux kernel, and available to everyone without jumping through hoops. Even 16-bit applications work Credit: Source: Scott Hardy/Github If NTSYNC is the headline feature, the completion of Wine's WoW64 architecture is the change that will quietly improve everyone's life going forward. On Windows, WoW64 (Windows 32-bit on Windows 64-bit) is the subsystem that lets 32-bit applications run on 64-bit systems. Wine has been working toward its own implementation of this for years, and Wine 11 marks the point where it's officially done. What this means in practice is that you no longer need 32-bit system libraries installed on your 64-bit Linux system to run 32-bit Windows applications. Wine handles the translation internally, using a single unified binary that automatically detects whether it's dealing with a 32-bit or 64-bit executable. The old days of installing multilib packages, configuring ia32-libs, or fighting with 32-bit dependencies on your 64-bit distro thankfully over. This might sound like a small quality-of-life improvement, but it's a massive piece of engineering work. The WoW64 mode now handles OpenGL memory mappings, SCSI pass-through, and even 16-bit application support. Yes, 16-bit! If you've got ancient Windows software from the '90s that you need to run for whatever reason, Wine 11 has you covered. For gaming specifically, this matters because a surprising number of games, especially older ones, are 32-bit executables. Previously, getting these to work often meant wrestling with your distro's multilib setup, which varied in quality and ease depending on whether you were on Ubuntu, Arch, Fedora, or something else entirely. Now, Wine just handles it for you. There are more fixes, too It's easy to let NTSYNC and WoW64 steal the spotlight, but Wine 11 is packed to the gills with other stuff worth talking about. Linux Follow Followed Like Share X Threads Bluesky Copy link Close Trending Now I set up Claude Code the way its creator does, and the difference is night and day Proxmox VE 9.1 can pull container images straight from Docker Hub, and it changes everything I carried the $54 Thinknode M5 everywhere for weeks, and now I want to build my own mesh network
Sign in to your XDA account We want to hear from you! Share your opinions in the thread below and remember to keep it respectful. Reply / Post Attachment(s) Please respect our community guidelines. No links, inappropriate language, or spam. Your comment has not been saved Sort by: Popular RikxianELE RikxianELE RikxianELE #FL001617 Member since 2024-11-10 Following 0 0 Follow Followed 0 Followers View The fact wine11 is making big development leaps and windows11 is enshitifying... What a time to be alive! Cant wait till wine1 beats windows11 and can support 95% off all apps and programs Upvote 2 Downvote Reply Copy John John John #MG281002 Member since 2024-11-28 Following 0 0 Follow Followed 0 Followers View Wait, since Wine was already faster than Windoze in several games this change means... Uh-oh. Microslop is f'd. Upvote 1 Downvote Reply Copy Paddy Paddy Paddy #SU814387 Member since 2025-10-19 Following 0 0 Follow Followed 0 Followers View Note that Ubuntu 24.04 LTS also has a suitable kernel version, 6.17, if you use HWE, available in the standard repositories. Upvote Downvote Reply Copy Cláudio Cláudio Cláudio #JF967707 Member since 2024-08-21 Following 0 0 Follow Followed 0 Followers View There is a big, enormous factual error this article presents. It says fsync isn't in the mainline kernel but it has been for years. It has been in kernel 5.16 which was released in January 2022, hence more than 4 years. Just read the kernel 5.16 changelog and you will see mention of "futex_waitv" -- that's fsync for you. The discussion before adding this feature to the kernel was also long -- you can get messages from at least 2 years prior to it.That's something anyone mildly used to linux gaming should know. When you run sime proton game with 'PROTON_LOG=1 %command%`' on the launch parameters just to see the string "fsync: up and running". Upvote Downvote Reply 1 Copy Adam Adam Adam #MN479559 Following 0 0 Follow Followed 10 Followers View futex2 is not the same as fsync. They are similar, but different, as fsync utilizes futex2. Futex2 wasn't relevant to this story as it was developed by André Almeida who did not contribute to NTSYNC. This is about the bring-up from esync, to fsync, to NTSYNC. In fact, WINE didn't support fsync/futex2 out of the box, and required people to patch it and export an environment variable to use it, such as by compiling it with WINE-TKG. Proton also implemented it. While fsync and futex2 are similar, they aren't the exact same. Upvote Downvote Reply Copy Brandon Brandon Brandon #WX206735 Member since 2025-03-21 Following 0 0 Follow Followed 0 Followers View Yes, but until I can run BlueStacks on Wine or Proton, I'm not interested. Upvote Downvote Reply 5 Copy Patrizio Patrizio Patrizio #LW598544 Member since 2024-01-27 Following 0 0 Follow Followed 0 Followers View I hope you're trolling. Why would you run a Linux emulator on top of a Windows emulator on top of a Linux OS? There are far better alternatives to run Android apps in Linux. Upvote 2 Downvote Reply Copy Codey Codey Codey #CQ924516 Member since 2026-03-24 Following 0 0 Follow Followed 0 Followers View Wine: Originally a recursive acronym for "Wine Is Not an Emulator" Upvote Downvote Reply Copy Brandon Brandon Brandon #WX206735 Member since 2025-03-21 Following 0 0 Follow Followed 0 Followers View Patrizio I'm sorry. I have tried Genymotion, Waydroid, and even Android Studio's emulator. None have measured up to BlueStacks in terms of the number of games that are playable on that emulator.But then again, it could just be a "me" problem — or, more accurately, a "my hardware" problem......I have a Kaby Lake CPU which isn't supposed to be able to run Windows 11, at least by Microsoft's standards, but it runs just fine for me. My GPU is a dinosaur compared to what's hot today — I have a Radeon R9 270X with a paltry 2GB of VRAM. I suppose that's why a lot of Android games won't run properly on my end, but BlueStacks has really worked wonders for my use case.Now, ideally, I would love a native Linux version of BlueStacks, but sadly, that's just not in the cards. Upvote Downvote Reply Copy Simon Simon Simon #JI623413 Member since 2026-03-24 Following 0 0 Follow Followed 0 Followers View Instead of just making fun of them, perhaps you could name some of those ways so they can educate themselves... Upvote Downvote Reply Copy CajunMoses CajunMoses CajunMoses #LG480227 Member since 2024-01-01 Following 0 0 Follow Followed 0 Followers View (Ahem.) If you want to know how we run Android apps on a Linux distro, it's by using a little thing that we call Waydroid. Puts BlueStacks to shame. 😜 Upvote Downvote Reply Copy Dominic Dominic Dominic #KC052628 Member since 2024-08-01 Following 0 0 Follow Followed 0 Followers View I wonder if this does anything for anti-cheat software? Upvote Downvote Reply Copy CajunMoses CajunMoses CajunMoses #LG480227 Member since 2024-01-01 Following 0 0 Follow Followed 0 Followers View This is extremely important work. I haven't personally found much use for Wine, as I severed my connections to Windows and Windows applications years ago. These days, I mostly use Flatpaks, Web apps, and Waydroid apps. But new migrants from Windows to Linux potentially benefit greatly from having this as a way make their transition into Linux apps less jolting as they move away from Windows apps. And for hardcore gamers, it's clearly kind of a really, really big deal. Upvote Downvote Reply Copy Erik Erik Erik #IE501879 Member since 2025-08-17 Following 0 0 Follow Followed 0 Followers View ntsync was rolled out to the mainline kernel OVER a year ago (Jan 2025) and wine included it in Jan 2026 but good on you for staying up to date in the news Upvote 1 Downvote Reply 5 Copy Robin Robin Robin #LV053979 Member since 2025-06-29 Following 0 0 Follow Followed 0 Followers View Wine 11's first stable release was just two months ago, that's not THAT long. I suppose the author was reminded to make a post like this when they saw Wine 11.5 being released a few days ago. That being said, 11.5 biggest feature (Syscall User Dispatch) is not discussed in this post.NTSYNC's inclusion into the kernel was great but not actually useful until something started to actually use it. Theres plenty of stuff that gets included in the kernel but isnt useful yet because its still stubbed out, disabled by default, doesn't have implementations in userland, etc etc etc. Upvote 2 Downvote Reply Copy Adam Adam Adam #MN479559 Following 0 0 Follow Followed 10 Followers View This article is about Wine 11's advancement which many didn't know about. NTSYNC being a part of the kernel doesn't really mean much without applications that use it, and with Wine 11.5 bringing Syscall User Dispatch, it felt like as good a time as any to break down what NTSYNC is and its history. If you already knew about it, then good for you! But not everyone does.In fact, I even mentioned that NTSYNC was merged in 6.14."Elizabeth Figura has been working on this problem for years, iterating through multiple kernel patch revisions, presenting the work at the Linux Plumbers Conference in 2023, and pushing through multiple versions of the patch set before it was finally merged into the mainline Linux kernel with version 6.14." Upvote 7 Downvote Reply Copy Minooch Minooch Minooch #YD478724 Member since 2026-03-24 Following 0 0 Follow Followed 0 Followers View Thanks Adam, I for one was unaware until your article was sent my way.As much as we love Linux & the billion distros, don't let the very vocal users that still live in Mummy's basement deter you Upvote 2 Downvote Reply Copy CajunMoses CajunMoses CajunMoses #LG480227 Member since 2024-01-01 Following 0 0 Follow Followed 0 Followers View Adam Yes, this. At first, I thought that this article was an unnecessarily long read. Then I realized that it had to be a work of passion, possibly obsession. Above all, it's a way of recognizing the monumental individual efforts involved in getting Wine to this point. Particularly when it comes to Linux, it's impossible to overstate how important it is to recognize the seemingly tireless labor that those who have this rare talent are willing to expend to make Linux "just work" for the rest of us. Upvote 2 Downvote Reply Copy Terms Recommended Ubuntu's folder icons got redesigned twice in a week because users can't agree on how they look Nintendo built the 3DS to be unhackable, but a $5 puzzle game and a QR code proved them wrong I reverse engineered my NAS's dead touchscreen and built an open-source dashboard from scratch I tried running games at native resolution again, but DLSS 4.5 changed my mind Shorts By Alex Dobie 1:24 The next Xbox is a PC. And your PC is now an Xbox. By Alex Dobie 1:15 What was the best version of Windows? By Alex Dobie 1:14 3 PC gaming anniversaries from 1996 By Alex Dobie 1:08 How much data does Steam use in a year? By Alex Dobie 1:32 Mac OS X launch: 25 years later Join Our Team Follow Us Advertising XDA is part of the Copyright © 2026 Valnet Inc. |
Wine 11 represents a significant leap forward in how Linux handles Windows games, fundamentally rewriting the kernel-level interaction. The speed gains achieved are truly massive, a direct result of numerous, carefully implemented changes and bug fixes. This isn’t simply another yearly update with minor tweaks; it’s a project that has been evolving for years, spearheaded by Elizabeth Figura, and culminates in a revolutionary approach to synchronization. The core of this advancement lies in the introduction of NTSYNC, a new kernel driver that directly models the Windows NT synchronization object API. Previously, Wine relied on cumbersome workarounds like esync and fsync, which approximated Windows' native synchronization mechanisms. These solutions, while effective, were inherently inefficient, introducing overhead through RPC calls and complex emulation. Figura’s work recognized this bottleneck and designed a solution that operates directly within the Linux kernel, utilizing its native capabilities for efficient thread coordination. The development of NTSYNC involved numerous iterations and refinements, culminating in its inclusion within the mainline Linux kernel with version 6.14. This is a critical distinction. By integrating NTSYNC directly into the kernel, Wine avoids the performance limitations of prior solutions. The impact of this change is immediately apparent in benchmark results. For instance, Dirt 3, which previously struggled to maintain a consistent 110.6 FPS in Wine, soared to an astonishing 860.7 FPS – a 678% performance increase. Similar gains were observed across other games, including Resident Evil 2 (26 FPS to 77 FPS) and Call of Juarez (99.8 FPS to 224.1 FPS), with Tiny Tina’s Wonderlands seeing gains from 130 FPS to 360 FPS. Notably, Call of Duty: Black Ops I, often a notoriously difficult game to run on Linux, finally became genuinely playable. These numbers represent not just theoretical improvements, but tangible, measurable differences in gaming performance. Beyond NTSYNC, the completion of Wine’s WoW64 architecture overhaul is another pivotal enhancement. WoW64, the subsystem responsible for allowing 32-bit Windows applications to run on 64-bit Linux, has been a long-standing area of focus for Wine developers. Finally, with Wine 11, this architecture is fully implemented and operational, eliminating the need for users to manually install multilib packages or configure complex dependency chains. This simplification dramatically reduces the barrier to entry for running 32-bit Windows games, a category of titles that frequently requires considerable technical expertise to properly configure. Furthermore, Wine 11 includes improvements to the Wayland driver, enhancing clipboard support and resolving issues related to drag-and-drop functionality between Wayland applications and Wine. It has also made strides in improving compatibility of older games to run on Wayland, a desktop environment. Beyond this, there are numerous other fixes and improvements addressing various bugs, optimizing performance across a range of games, and providing enhancements for graphics rendering, audio processing, and input devices. These refinements, collectively, contribute to a significantly more stable and performant gaming experience. The integration of these changes doesn't guarantee that every game will benefit equally. Some titles, particularly those with less complex synchronization requirements, may see only marginal improvements. However, for those games that are heavily reliant on multi-threaded operations and exhibit performance bottlenecks related to thread coordination, the gains achievable with NTSYNC are substantial. The success of NTSYNC underscores a shift in Wine’s development philosophy – one that prioritizes kernel-level optimization and direct integration with the operating system’s core functionalities. This approach represents a fundamental change in how Wine interacts with Windows games, moving away from emulation and approximation towards true, native implementation. Moreover, because of this change it's now being delivered with SteamOS, and Proton, which means that every Steam Deck owner, as well as anyone running Proton on Linux, will benefit from these improvements immediately. The introduction of NTSYNC and the completion of WoW64 represent a watershed moment for Linux gaming, effectively unlocking the full potential of Windows games on the platform. |