Wine 11 rewrites how Linux runs Windows games at the kernel level, and the speed gains are massive
Wine 11 rewrites how Linux runs Windows games at the kernel level, and the speed gains are massive
What is often overlooked
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.
Ntsync is great and there will be performance improvement. But not exactly massive
XDA will write articles these days like:
I painted my NAS red and you won’t believe the improvements
Orks approve
I painted my NAS red and you won’t believe the improvements
Okay this just unlocked a random memory. Back when I worked at a call center, on a slow day a lady called about a product that we no longer directly supported, and she went on a huge tangent about how everything she buys is bright red to remind her of the fires of hell. Bright red purse, bright red clothing, bright red phone, bright red computer, etc. she also told me quite a bit about a religious children’s book series she wrote about a Christian dog
Gamers who use fsync are not going to see such a leap in performance in most games.
I don’t think that’s overlooked at all. 99.9% of people using WINE/Proton aren’t going to have any idea what fsync is, and almost nobody not using proton-cachyos is going to use it. fsync, itself a workaround, is niche within what’s already a niche.
From what I found online, Steam enables esync by default, and fsync if your kernel supports it.
Lutris has both options nowadays in the runner settings. Idk if they’re both enabled by default, but in my case they’re enabled. ymmv there.
From the article:
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.
So since Jan 2022, it’s been in the stable Linux kernel. For Debian and its derivatives, it would be included beginning with Bookworm.
99.9% of people using WINE/Proton aren’t going to have any idea what fsync is
Speaking, although I’ve heard the term thrown around a lot. Can I get a layman’s overview?
You’re right, it is.
You can try all you want, but you will never get me to read the articles before commenting.
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.
These don’t sound massive to you?
zcat /proc/config.gz | grep -iE ‘ntsync|esync|fsync’ and saw that I only have ntsync which is a module and is unloaded! Now I have it loaded and set to autoload on boot so I’m ready for better performance. This is with the Arch Zen kernel. Thanks!
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.
Oh, thank heavens. I remember advising some users here to look for specifically missing 32-bit host Linux library support; I’d run into that problem before.
It may be heresy, but at that point, just run the Windows version over the linux one, yes.
The amount of games that:
Have linux builds,
that run noticably better than the Windows executable through Wine/Proton
yet require 32-bit linux libs,
in 2026?
Must be zero, or close to it.
Besides, I love the meme that “Wine is a better gaming platform than native linux, or native Windows.” There’s something so satsifying about robbing Microsoft’s own API with such wild success.
I don’t think it’s heresy, but I do think there’s value in devs shipping native Linux builds. It’s a Mindshare thing. If devs never target Linux they won’t build with Linux in mind.
But as a user, it’s fine to use whichever version gives the best performance.
If devs never target Linux they won’t build with Linux in mind.
Won’t they?
I posit this:
Windows gaming will die. Slowly.
Devs will target Proton more and more explicitly.
…Until development is basically exclusively targing Wine/Proton, on Linux.
It’s easy to laugh at that as a meme, but does Windows seem sustainable now? Is there any sane “single target” for game devs other than Proton? Is it not the path of least resistance, by an order of magnitude? Hence I think that’s legitimately what will happen.
It’s easy to laugh at that as a meme
No, you definitely have a point. An increasingly valid one, I might add.
And I do wonder what the “point” of Wine will be overall if we ever get to the point where the majority of users are on Linux.
And I do wonder what the “point” of Wine will be overall if we ever get to the point where the majority of users are on Linux.
Nothing! If Windows parity isn’t a concern, they don’t have to develop anything. They can leave Wine how it is, and everything just works! In fact, keeping it as a stable API would be less of a headache for apps that target it.
WINE becomes a “universally compatible linux API” that happens to be backwards-compatible with Windows executables.
What’s more, they could add whatever features and fixes they want, unbound by Microsoft. Game studios could even PR the project, I suppose.
I’m not sure that would ever happen, though. Business users will be stuck with Windows forever, hence parity with Windows desktop apps will remain a goal.