Support us on Patreon
PayPalIt seems the ongoing saga of getting the futex2 work into the Linux Kernel, which is supposed to help Linux gaming and Steam Play Proton, has another attempt up. This is a continuation of the cut-down and more focused code that was submitted back in early August, as Collabora hope to finally get it accepted into the Kernel.
The key point is that this code is not just to help Windows games on Linux through Proton but to also help native games. While the code better matches behaviour found on Windows, anything that needs it can benefit. As developer André Almeida explains:
"The use case of this syscall is to allow low level locking libraries to wait for multiple locks at the same time. This is specially useful for emulating Windows' WaitForMultipleObjects. A futex_waitv()-based solution has been used for some time at Proton's Wine (a compatibility layer to run Windows games on Linux). Compared to a solution that uses eventfd(), futex was able to reduce CPU utilization for games, and even increase frames per second for some games. This happens because eventfd doesn't scale very well for a huge number of read, write and poll calls compared to futex. Native game engines will benefit of this as well, given that this wait pattern is common for games."
Since we last wrote about it, two new versions of it have been sent in so it's now on the third iteration with these changes and improvements:
Changes from v2:
v2: https://lore.kernel.org/lkml/[email protected]/
- Last version, I made compat and non-compat use the same code, but
failed to remove the compat entry point. This is fixed now.
- Add ARM support
Changes from v1:
v1: https://lore.kernel.org/lkml/[email protected]/
- Tons of code and comment improvements and fixes (thanks Thomas!)
- Changed the struct to have explicit padding (thanks Arnd!)
- Created a kernel/futex.h
- Splitted syscall table changes from the implementation
- Compat and non-compat entry point now uses the same code and same
struct
- Added test for timeout
You can see the patches on the Linux Kernel mailing list.
Article taken from GamingOnLinux.com.
The first two attempts got rejected?Rare is the patch series affecting system calls, new file systems, schedulers or otherwise performance related, that makes it into the Linux kernel on the first attempt. When it takes more then 7 revisions, then you should start to worry. Memory folios, an important rework of memory handling, are on their 14th iteration right now. (https://www.phoronix.com/scan.php?page=news_item&px=Folios-Pagesets-MIA-5.15) Folios only change internal APIs, while new system calls, as part of the kernel external API, will be maintained forever.
Last edited by Pikolo on 14 September 2021 at 12:37 pm UTC
The first two attempts got rejected?Yeah, there've been articles here about those. But you know, looking at the little "changes" bit there, I don't understand a word about what specifically they changed, but I get the impression that criticism by Serious Kernel Types was constructive and resulted in real improvements to the code, and also that the third version changed a lot less than the second version, which suggests that the heavy lifting of meeting requirements was done after the original patch was critiqued, while the third version was just taking care of a couple of loose ends.
That seems like real progress, not stonewalling, and seems like maybe either this third one will be accepted, or a couple of other loose ends might turn up but at any rate we're getting close.
TheRiddick Sep 15, 2021
This is one of the reasons I think Steam Deck might ship with Valve's custom kernel, with Futex2 and probably some other out of tree patches.
probably with some form of drm to convince netflix and others to support it (netflix already works on linux at 720p, but im not sure about disney+ and others)
and the deal they have with anti cheat solutions may include some kernel level features.
"- Add ARM support"
wth '-', serious? there is any wine-arm?
I guess having something included is easier if it tastes less like "our special solution to run proprietary software, on amd64 only".
"- Add ARM support"Wine is ported to Android and does (supposedly, I never tried it) run some WinRT applications on ARM.
wth '-', serious? there is any wine-arm?
Last edited by whizse on 16 September 2021 at 9:44 am UTC
applications is a thing that dont require an low input lag to work..."- Add ARM support"Wine is ported to Android and does (supposedly, I never tried it) run some WinRT applications on ARM.
wth '-', serious? there is any wine-arm?
i wonder how well it can play games
See more from me