Support us on Patreon
PayPalHere 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.
But yeah would be nice if it actually gets merged to mainline at some point.
there'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
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.
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
there'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 ^^
if 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.
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:
(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.
See more from me