FUTEX2 System Call Updated To Work On ARM

[phoronix]

Phoronix: FUTEX2 System Call Updated To Work On ARM

While Linux 5.15 has many new features and improvements, one of the patch series we have been eager to see land is the work introducing the new FUTEX2 system call. FUTEX2 can help improve the performance of newer Windows games running on Linux via Wine / Steam Play's Proton by better matching the Windows kernel behavior, but while it didn't land for Linux 5.15, at least a new version of the patches were posted...

https://www.phoronix.com/scan.php?page=news_item&px=FUTEX2-v3-Patches

[tildearrow]

Arm... Proton for Android/M1 soon?

[Danny3]

Ok with ARM, but are we getting closer for x86 ?
I will care about ARM compatibility in 5 years or so when phones will be powerful enough to drive a Linux distro and play games on it while streaming to 2K-4K screen.

[ms178]

Ok with ARM, but are we getting closer for x86 ?
I will care about ARM compatibility in 5 years or so when phones will be powerful enough to drive a Linux distro and play games on it while streaming to 2K-4K screen.

You know, there are a couple of performant ARM server chips today already, right?! But I agree, for desktop AAA gaming ARM still needs to improve its footprint and market share first (starting from 0).

[oiaohm]

You know, there are a couple of performant ARM server chips today already, right?! But I agree, for desktop AAA gaming ARM still needs to improve its footprint and market share first (starting from 0).

Its not just AAA games. Please don't forget retro. WaitForMultipleObjects in windows was added in Windows XP and used in games a lot since then. This is 2001-2002 games at the earliest.

https://www.intel.com/pressroom/kits...refyr.htm#2001 Yes the CPU from the 2001-2002 time frame we are starting to see arm chips appear that could be competitive with.

https://www.glennklockwood.com/benchmarks/performance.html

Yes it kind of a surprise to people that Raspberry pi 4 single core performance is competitive up a Pentium D from 2005 while consuming way less power. Yes it warped that a 1.5 Ghz ARM Cortex-A72 in Pi 4 is performance competitive with a 3.2 Ghz Pentium D.

So its now if the emulation overhead can be got low enough. Yes FUTEX2 is kind required if wine hangover is going to work for the early games using WaitForMultipleObjects on items like the Raspberry PI because the overhead of emulating WaitForMultipleObjects inside existing wine is going to take too much performance.

There are still quite a number new games for windows released every year that will run on a 3.2 Ghz Pentium D amount of performance. Yes these are not you AAA titles.

Yes Raspberry pi 4 are used by a lot of people for retro gaming setups. So adding some windows games to their console game emulation.

[Alex/AT]

Am I missing something, or the incomplete 'plug one kind of situation' code with

+/*
+ * Flags to specify the bit length of the futex word for futex2 syscalls.
+ * Currently, only 32 is supported.
+ */
+#define FUTEX_32 2

is planning to land on mainstream kernel? I won't wonder if it don't for another year or so.

It was even already commented by "Why start at 2?", because indeed why.
The reason is clear, there were some other variants planned, but hastily removed because nobody implemented them.
Another question that immediately comes to mind after changing this is 'why keep the one and only zero flag'. Same reason.
So the feeling is removing the flag completely would have been more reasonable.

[cl333r]

2058: FUTEX2 System Call Updated To support Absolutely Anything. Still Not Merged To Master.

[F.Ultra]

Am I missing something, or the incomplete 'plug one kind of situation' code with

+/*
+ * Flags to specify the bit length of the futex word for futex2 syscalls.
+ * Currently, only 32 is supported.
+ */
+#define FUTEX_32 2

is planning to land on mainstream kernel? I won't wonder if it don't for another year or so.

It was even already commented by "Why start at 2?", because indeed why.
The reason is clear, there were some other variants planned, but hastily removed because nobody implemented them.
Another question that immediately comes to mind after changing this is 'why keep the one and only zero flag'. Same reason.
So the feeling is removing the flag completely would have been more reasonable.

They are planning to add other sizes later, they just cut all that away to simplify the patch in order to increase the chance of having it merged.

[Alex/AT]

They are planning to add other sizes later, they just cut all that away to simplify the patch in order to increase the chance of having it merged.

Indeed merge can be done later too. As it plugs just one distinct hole in one single application and is specialized for it, it may just live as a third party patch.
Not saying it's not a good thing, but it surely does not feel generic enough at all.

[F.Ultra]

Indeed merge can be done later too. As it plugs just one distinct hole in one single application and is specialized for it, it may just live as a third party patch.
Not saying it's not a good thing, but it surely does not feel generic enough at all.

No, a merge is quite needed if Proton is going to have a wider usage of the functionality besides the Steam Deck.