Linux 5.16 Released With Many Intel & AMD Additions, Memory Folios, AMX, FUTEX2

[CochainComplex]

Wow I did not expect that either. Thanks for the link and Shmerl for asking all that info!

shmerl THX for the interrogation very surprising. I thought it was the wine community pushing for in tree acceptance.

[shmerl]

shmerl THX for the interrogation very surprising. I thought it was the wine community pushing for in tree acceptance.

Yeah, I didn't know that either. Apparently there is no good solution for this (at least now?). Proton might use it, but Wine won't. At least it's good to know there are very few cases when it's actually useful. And Wine staging still has esync so far.

[partcyborg]

Luckily the 5.16 kernel can be installed manually from that link or easier with Ubuntu Mainline Kernel Install third party too, but still some badly designed software like AMD proprietary drivers might refuse to install if it's not the original kernel version that Ubuntu 22.04 came with.
For that case it's important that Ubuntu comes with an up-to-date kernel as possible.

What? are you talking about the amdpro proprietary graphics drivers? Because those are entirely in userland, and are therefore essentially kernel agnostic. I'm not aware of any AMD closed source kernel modules.

[Linuxxx]

Yeah, I didn't know that either. Apparently there is no good solution for this (at least now?). Proton might use it, but Wine won't. At least it's good to know there are very few cases when it's actually useful. And Wine staging still has esync so far.

Except the fact that Esync destroys consistent frametimes & makes shader-compile stutter unbearable; e.g. Battlefield 1, Dishonored 2, Batman - Arkham Knight, S.T.A.L.K.E.R. - Anomaly, etc.

At least the Lutris-GE builds are already shipping the necessary patches for Fsync, which any sane person already gravitated towards years ago anyway, so upstream WINE's gatekeeper CodeWeavers can carry on caring about their paying Mactard customers!

[Amano]

Maybe phoronix should remove the WINE reference in the article and change it to Proton

[Nocifer]

Yeah, I didn't know that either. Apparently there is no good solution for this (at least now?). Proton might use it, but Wine won't. At least it's good to know there are very few cases when it's actually useful. And Wine staging still has esync so far.

Apparently Valve and Collabora have been consistently funneling their efforts towards implementing and upstreaming futex_waitv for some time now, and apparently they know what they're doing since, due to their previous efforts, Wine has already transitioned from a mostly useless theoretical concept to a workable solution that's bound to change the Linux ecosystem; which means that apparently futex_waitv is already a good solution (predictable, since it's an evolution of the fsync concept and fsync is already good for many games, despite what that Wine dev was trying to say).

So apparently we should maybe start treating Valve and Collabora as the authorities-that-be on Wine development in place of the original Wine team, because the former apparently care about evolving Wine into a proper real-world solution that solves real-world use cases (even if they only care due to their desire to make it into a profitable product) while the latter are apparently growing more and more comparable to the GNU purists, systemd haters and the various other anachronistic entities that plague Linux these days. If we relied on them and their concepts of what's worthy to be merged and what isn't, we'd still be "playing" DX11 games in single digit framerates. Bah.

Please, do note that the bitter sarcasm is aimed not at you but at the Wine devs. Back when I told you (don't know if you remember our discussion) that I wasn't expecting futex_waitv support to be merged in Wine before at least both kernel 5.16 and Wine 7.0 were out of the door, I certainly wasn't expecting for it to be blocked from being merged indefinitely by the Wine devs due to Reasons™ - i.e. just as they've done with DXVK.

[Weasel]

Apparently Valve and Collabora have been consistently funneling their efforts towards implementing and upstreaming futex_waitv for some time now, and apparently they know what they're doing since, due to their previous efforts, Wine has already transitioned from a mostly useless theoretical concept to a workable solution that's bound to change the Linux ecosystem; which means that apparently futex_waitv is already a good solution (predictable, since it's an evolution of the fsync concept and fsync is already good for many games, despite what that Wine dev was trying to say).

So apparently we should maybe start treating Valve and Collabora as the authorities-that-be on Wine development in place of the original Wine team, because the former apparently care about evolving Wine into a proper real-world solution that solves real-world use cases (even if they only care due to their desire to make it into a profitable product) while the latter are apparently growing more and more comparable to the GNU purists, systemd haters and the various other anachronistic entities that plague Linux these days. If we relied on them and their concepts of what's worthy to be merged and what isn't, we'd still be "playing" DX11 games in single digit framerates. Bah.

Please, do note that the bitter sarcasm is aimed not at you but at the Wine devs. Back when I told you (don't know if you remember our discussion) that I wasn't expecting futex_waitv support to be merged in Wine before at least both kernel 5.16 and Wine 7.0 were out of the door, I certainly wasn't expecting for it to be blocked from being merged indefinitely by the Wine devs due to Reasons™ - i.e. just as they've done with DXVK.

"Maintenance burden" I can sort of understand a bit, but honestly the entire logic in his "it's not secure, it's not how Windows does it" makes no sense. esync (and fsync) are hidden behind options (environment variables, could also be registry keys).

They should stop trying to decide what users decide to opt-in for. If they don't give a shit about security and want performance THEN LET THEM. This is as cringe as the idiots who put mitigations up without a way to disable them.

[Danny3]

What? are you talking about the amdpro proprietary graphics drivers? Because those are entirely in userland, and are therefore essentially kernel agnostic. I'm not aware of any AMD closed source kernel modules.

Yes, the proprietary or whatever is downloaded from their website that you need for any kind of compute.
Last time I tried it, it was very picky about using an old LTS version of Ubuntu and an old kernel.
I really hated it.

[F.Ultra]

People running Ubuntu should not be caring about the latest and greatest.... Either accept the older and more stable or hop on a distro that runs more modern stuff.... You can't have both

He was talking about an yet not released version of Ubuntu, so the "older and more stable" does not apply here. An LTS becomes stable once released, not before that.

[cytomax55]

I appreciate what he was saying...
I too was the same way for a year or so running kubuntu ..
My simple point is if you're worried about what kernel your system is going to be running you should probably be running a different distro....
Ubuntu is about stability and reliability And you'll go crazy always wanting the latest kernel or worse yet you'll take a stable Ubuntu and start trying to put the newer kernels into it....
Maybe it's normal progression for Linux users cuz that's what I went through and eventually I landed on Manjaro I was just trying to save him the build up of time to the decision to bounce to a different distro but I guess you just can't speed up experience