Updated FUTEX2 Patches Posted For The Linux Kernel With A Focus On Helping Games

[duby229]

It's not that Linux systems can't meet those needs, they totally can. There are no technical restrictions. The DRM restrictions are artificial and imposed by big media publishing companies. They'll never play premium content on platforms that the user can control. The instant the user takes control and changes something, they lose the ability to play DRM content. Sometimes permanently.

As an example, I installed a custom ROM on my personal device because the default one had problems. It was downgraded to L3. Installed Netflix on it too, and of course it played only SD content. Then I went back to the stock OS, locked bootloader, no root or customisations. API says Widevine L1 is supported, Google's Play Movies and TV is happy to play 1080p and even 1440p content. Netflix refused to play HD content, it was stuck at SD (even though it's settings said it was L1 and HD). They'd obtained the device's unique hardware ID and denylisted on the server side. Can't change DRM hardware IDs. Permanent loss of HD playback even if you kowtow to their rules.

Time to hack then. The bottom line is this, regardless of marketshare percentage, the raw numbers mean there are -millions- of Linux users. Once the -mechanisms- are put in place so that implementations can be made, any corporation that doesn't work will be outcompeted. Free market economics actually -does- work.

[Guest]

Time to hack then. The bottom line is this, regardless of marketshare percentage, the raw numbers mean there are -millions- of Linux users. Once the -mechanisms- are put in place so that implementations can be made, any corporation that doesn't work will be outcompeted. Free market economics actually -does- work.

But...... implementations can be made...... nothing really stopped them upto now. On Windows, they never cared about having encrypted GPU memory and stuff until recently. It's only for 4K content that Netflix started requiring encrypted GPU memory (which was only supported on Intel Kabylake at the time). More recently, NVIDIA and AMD have also added this feature of encrypted GPU memory.

And hardware accelerated H.264 video decode has been available since Intel Ironlake......

The media publishing companies don't care that much about market share, and if they do, they'll start demanding locked down computers and verification to play DRM media.

Consumers won't move over en-masse to a full Linux desktop because they can't see their favourite movies and shows in HD. It's a chicken and egg situation.

[duby229]

But...... implementations can be made...... nothing really stopped them upto now. On Windows, they never cared about having encrypted GPU memory and stuff until recently. It's only for 4K content that Netflix started requiring encrypted GPU memory (which was only supported on Intel Kabylake at the time). More recently, NVIDIA and AMD have also added this feature of encrypted GPU memory.

And hardware accelerated H.264 video decode has been available since Intel Ironlake......

The media publishing companies don't care that much about market share, and if they do, they'll start demanding locked down computers and verification to play DRM media.

Consumers won't move over en-masse to a full Linux desktop because they can't see their favourite movies and shows in HD. It's a chicken and egg situation.

I'm arguing that there are -already- enough Linux users to justify it. Millions of us -right now-... The egg has already hatched and the chicken is full grown...

[Guest]

I'm arguing that there are -already- enough Linux users to justify it. Millions of us -right now-... The egg has already hatched and the chicken is full grown...

Yeah, but the media publishing companies still won't play HD video on a system where users have control. Sure there may be millions of Linux users, but there are also billions of non-Linux users who don't know or care about the DRM. Plus many Linux users like me also use other devices like phones, tablets, Windows, Smart TVs etc. to watch DRM content.

So the percentage of people using Linux exclusively isn't enough to get media publishing companies to change their tack.

You have to hit them where it hurts - their wallet. Which means billions of people need to stop paying for
DRM protected content due to the lack of Linux support, to get the companies to change.

[Cybmax]

Since it seems EVERY topic on phoronix forums end up debating something completely unrelated, i hope i dont step on any toes to try to bring this back on topic.

I did some reading and testing, and from what i gather, FUTEX2 is not an addition to the previous fsync patches, it is a replacement - so that devs can work on that without the risks of breaking the "futex api" already existing in the kernel (since it might be finicky to figure out breakage here). By implementing futex2, it will not break current code using futex'es with the current kernel futex code. Atlest this is what i could figure out with my measly understanding.

Now, where i kinda do not completely follow is the "need" for upgrading glibc. Is an patched glibc needed for running wine with "max performance", or is it just to implement the api for future, so that "other libraries/binaries" would be compiled with "futex2 awareness"?

I kinda find it a bit odd that ppl are not jumping on this futex2 bandwagon asap, unless there is nothing to be gained atm perhaps? (Did SOME testing, and was so far little change tho). I like to experiment, so i will do so.. just got a wee bit unsure about this glibc patching, cos that is not as easy as patching the kernel and wine to make my own custom versions, since switching glibc on a running system might open a huge can of worms unless you are running a rolling distro with everything -git (Using Ubuntu20.04 myself, and i don't dare upgrade glibc, as i believe the breakage would be unrecoverable, and the proposed futex2 patches is not for 2.31 that is shipped with 20.04).

[schlemil]

Now, where i kinda do not completely follow is the "need" for upgrading glibc. Is an patched glibc needed for running wine with "max performance", or is it just to implement the api for future, so that "other libraries/binaries" would be compiled with "futex2 awareness"?

glibc has wrappers for most system calls. Usually, those wrappers are used instead of invoking the system calls directly. However, Proton is invoking the system call directly, so you don't need the glibc patches for Wine.

I wouldn't expect a noticeable performance difference. Futex2 was something like 4% faster in low level benchmarks, expect a lot less in actual games.

[Justin]

I heard someone saying that syscall user dispatch has since allowed Destiny 2 to work via wine without being banned. I don't remember where I read it but does anyone know if there's any validity to it?

[qarium]

I'm arguing that there are -already- enough Linux users to justify it. Millions of us -right now-... The egg has already hatched and the chicken is full grown...

absolutly right. as soon as valve/steam release true numbers of linux users instead of only %%% percentages the people will be stunned and their mind will go crazy.

we are already so big that any company who does not support linux on steam does in fact lose millions of dollars.