Don't want to see articles from a certain category? When logged in, go to your User Settings and adjust your feed in the Content Preferences section where you can block tags!
We do often include affiliate links to earn us some pennies. See more here.

Here we go again, open source consulting firm Collabora have sent in the futex2 patches to the Linux Kernel for a fourth time now even more work has been done with the aim to help Wine and Steam Play Proton.

Why a new version of futex? As they explain:

For some years now, developers have been trying to add new features to futex, but maintainers have been reluctant to accept then, given the multiplexed interface full of legacy features and tricky to do big changes. Some problems that people tried to address with patchsets are: NUMA-awareness[0], smaller sized futexes[1], wait on multiple futexes[2]. NUMA, for instance, just doesn't fit the current API in a reasonable way. Considering that, it's not possible to merge new features into the current futex.

Not sure on what all of this is? You're not alone. Kernel stuff can be incredibly confusing and difficult to understand if you're not already well versed. Essentially: the futex2 patches should enable better performance of Windows games running on Linux through Wine and Steam Play Proton as it better matches Windows behaviour. If you want to catch up on it and see some background, check out our previous article with a presentation from Collabora.

This has been in progress for quite a long time now, while they get more feedback on it and try to improve it further. This fourth attempt implements "variable sized futexes" which was another feature requested and needed. It's still likely to be a while before being accepted into the Linux Kernel and even then you're in for a wait for a new Kernel release, distribution updates and then Proton / Wine updates to work with it.

Eventually though, we will hopefully see even better Windows gaming performance on Linux.

Article taken from GamingOnLinux.com.
20 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
8 comments

Xpander Jun 4, 2021
Luckily running custom kernels with patched in futex2 or any other gaming related work isn't hard these days.
But yeah would be nice if it actually gets merged to mainline at some point.
CatKiller Jun 4, 2021
View PC info
  • Supporter Plus
More easily translating Windows' behaviour to Linux was obviously the primary initial motivation, but I don't think it will end up as the only one. Being able to wait for one of many signals seems like the kind of thing that would be generally useful; there's a reason Windows has that function, after all.
tuubi Jun 4, 2021
View PC info
  • Supporter
Quoting: CatKillerthere's a reason Windows has that function, after all.
As we all know, Windows is the benchmark all kernels should scramble to imitate.
DamonLinuxPL Jun 4, 2021
Quoting: XpanderLuckily running custom kernels with patched in futex2 or any other gaming related work isn't hard these days.
But yeah would be nice if it actually gets merged to mainline at some point.

Well, to take full advantage of Futex2 you need patch at least two more packages. One is WINE (or use Proton Experimental), seconds is GLIBC and this is much harder way. Not too much distros use patched GLIBC...
We at Mandriva maintaining these patches at Glibc for over a year. Like, for example, here https://github.com/OpenMandrivaAssociation/glibc/commit/2dd211b562923769b05e3e41f53270ec6f62ffbb


Last edited by DamonLinuxPL on 4 June 2021 at 12:32 pm UTC
Termy Jun 5, 2021
Quoting: CatKillerthere's a reason Windows has that function, after all.

if i recall correctly, it's more about better compatibility with games doing something outside the official windows-system-calls?
Besides that: what tuubi said ^^
CatKiller Jun 5, 2021
View PC info
  • Supporter Plus
Quoting: Termyif i recall correctly, it's more about better compatibility with games doing something outside the official windows-system-calls?
No, that's a different thing. It's syscall user dispatch that bounces stray Windows system calls back to Wine for processing.

This one is about adding capabilities to futex that weren't thought of back in 2002 - including some that are in Windows' later implementation, which are used by developers making applications for Windows - without breaking userspace applications that are already using the original futex.
slapin Jun 7, 2021
  • Supporter Plus
Looks like a giant can of worms patchset, adding new syscalls is for serous heroes. Also there is not point in just implementing futex2, one should reimplement all existing userspace locking mechanisms in glibc which use futex now to futex2 to gain something. Just adding new syscall for wine is not worthy it at all and pointless.
redmcg Jun 9, 2021
It's worth taking a look at the following post by Zebediah Figura:
https://lore.kernel.org/lkml/[email protected]/

Zebediah is of Codeweavers, and author of the esync and fsync patchsets used by Proton. In that post, she states that this patchset may not be needed by Wine (or Proton) and makes the following three points:

Quote(1) this out-of-tree implementation is only in a small handful of cases
any more performant than a different out-of-tree implementation which
uses eventfd and poll() instead;

(2) these implementations will remain out-of-tree due to compatibility
and robustness problems;

(3) I believe there is potential for an upstreamable implementation
which does not rely on futex or futex2.

In otherwords (my interpretation is):
1. The fsync patchset (which would use the proposed futex2 patchset) is only better than the esync patchset in a small handful of cases;
2. Neither the fsync or esync patchsets will make it in to an official release of Wine; and
3. There's the potential for a solution that can be used in Wine that won't make use of the esync, fsync or futex2 patchsets.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.