It’s not merged, but the benchmarks are against upstream wine. Proton has hacks (fsync) that have almost identical performance uplift but were not suited to upstreaming.
So basically this will improve “correctness” versus current Proton, not performance. Should fix some bugs and improve compatibility.
Versus stock wine, it’s a huge perf uplift though.
atzanteol@sh.itjust.works
on 09 Jul 2024 04:49
nextcollapse
I promise I won’t go more into the tech bits meant for developers
I truly hate authors who speak down to me.
steeznson@lemmy.world
on 10 Jul 2024 21:24
collapse
Often you see that in blog posts where the author themselves doesn’t fully understand the details.
morrowind@lemmy.ml
on 09 Jul 2024 05:08
nextcollapse
Basically implementing windows in the Linux kernel? Something about this is really funny
cyberpunk007@lemmy.ca
on 09 Jul 2024 05:44
nextcollapse
The Linux subsystem for windows.
fruitycoder@sh.itjust.works
on 11 Jul 2024 06:55
collapse
I mean good ideas are good ideas. Even if not all of the windows kernel implementation is good it would be to learn from what works still
Vash63@lemmy.world
on 09 Jul 2024 05:36
nextcollapse
It’s annoying all the articles are focusing on performance versus stock wine here when basically everyone uses Proton or a fork of it anyway, which has had fsync for years now that does similar performance uplift.
The story here should be that we’re getting fsync level performance with fewer bug and it can be upstreamed to wine. There is no relevant performance uplift for Proton users, but I guess performance gets clicks so that’s the story all the press are going with.
refalo@programming.dev
on 09 Jul 2024 06:21
collapse
I can’t believe stock wine is still so bad with so many games. GTA5 is still unplayable with a keyboard, it just freezes for 5 seconds with every single keypress.
unexposedhazard@discuss.tchncs.de
on 09 Jul 2024 07:42
collapse
I would just run external games through steam with proton if you have those kinds of issues.
MentalEdge@sopuli.xyz
on 09 Jul 2024 08:59
collapse
You don’t even have to do that.
Wine managers like Bottles make it extremely easy to slap on whatever fixes and wine variants you might need.
unexposedhazard@discuss.tchncs.de
on 09 Jul 2024 09:42
nextcollapse
Yeah for sure, thats better in every way, but if you dont want to install another application thats the easiest way.
How do you know what fixes/Wine variants you need?
MentalEdge@sopuli.xyz
on 09 Jul 2024 11:02
collapse
You google the game to see if smarter people have done the investigating.
If not, you parse logs and errors best you can and try to determine what needs enabling. If you get it working, share it on protondb.
Generally though, enabling “everything” doesn’t come with any direct drawbacks. This is basically what bottles will do when you tell it you want to run a game, which will then allow most games to work fine.
The latest version of GE is generally what you want, too, as wine/GE isn’t supposed to have regressions requiring the use of an older version with some games.
Ooops@feddit.org
on 09 Jul 2024 10:32
nextcollapse
Doing that improved performance for Windows apps on Linux when using Wine or Valve’s Proton that is based on the former.
[…]
benchmarks that show games running better with average improvement rates ranging from 50% to 150% when using the new driver compared to not using it.
Talking about improvements for Wine and Proton then providing no actual data for Proton (which is already using a completely different mehod for syncs - yes the basic wine method sucks) is either stupid or intentionally misleading.
While the initial driver patches were merged to char/misc and now in turn within Linux 6.10 Git, much of the enablement work wasn't accepted in time. Thus for Linux 6.10 the new NTSYNC driver is marked as "broken", so it won't even be built for normal kernel builds.
Hopefully for Linux 6.11 or sometime soon the rest of the NTSYNC patches are upstreamed for yielding this massive boost to Windows games on Linux.
Support for it already seems to be there in wine, so rather than wait for 6.11 I think I'll just go ahead and apply the patches myself to 6.10-rc7 and see if it makes any difference to the one game I regularly play. If my computer blows up as a result I'll let y'all know.
(Result: None. The versions of wine I have probably need patching or at least configuring in order to use it. In the course of briefly considering trying to work out how to do that, I discovered that the expected improvements are not nearly as dramatic as were suggested compared to what's already most often done in proton (fsync). The main benefit for most of us will be better compatibility, not huge performance gains. Well at least my kernel is ready for it.)
zbyte64@awful.systems
on 09 Jul 2024 14:14
collapse
o7
ElectroLisa@lemmy.blahaj.zone
on 09 Jul 2024 14:37
collapse
I’d like to see those numbers stacked against modern Proton/Wine-GE solutions focused on gaming, rather than stock Wine
threaded - newest
article from February, anybody got benchmarks? pretty sure this is long since merged and working iirc
Only thing I can find is this OS News article saying it should be in the 6.10 kernel
I can not find any confirmation that it is.
That quote actually links to a really good article: www.phoronix.com/news/Linux-6.10-Merging-NTSYNC
oh that makes more sense, for some reason I thought it was in 6.9 already
It’s actually being pushed as “broken” for 6.10 but should hopefully be completely available in 6.11.
It is merged in 6.10 which is about to be released on Sunday (14 July)
If you had read it you’d have answers to your questions.
They are trying to merge it in 6.11 bit has to go through Greg and Torvalds himself. The benchmarks, once again, speed-reader, are on the article.
No need to be rude.
It seems to me that Mactan was hoping for some independent recent benchmarks.
Presumably they wanted something a bit more thorough and clear than a table of numbers with no information besides:
It’s not merged, but the benchmarks are against upstream wine. Proton has hacks (fsync) that have almost identical performance uplift but were not suited to upstreaming.
So basically this will improve “correctness” versus current Proton, not performance. Should fix some bugs and improve compatibility.
Versus stock wine, it’s a huge perf uplift though.
I truly hate authors who speak down to me.
Often you see that in blog posts where the author themselves doesn’t fully understand the details.
“I’m healthy, I eat fruit, vegetables, etc.”
“What’s etc.?”
“Other things”
“Like what?”
“… Let’s move on.”
Basically implementing windows in the Linux kernel? Something about this is really funny
The Linux subsystem for windows.
I mean good ideas are good ideas. Even if not all of the windows kernel implementation is good it would be to learn from what works still
It’s annoying all the articles are focusing on performance versus stock wine here when basically everyone uses Proton or a fork of it anyway, which has had fsync for years now that does similar performance uplift.
The story here should be that we’re getting fsync level performance with fewer bug and it can be upstreamed to wine. There is no relevant performance uplift for Proton users, but I guess performance gets clicks so that’s the story all the press are going with.
.
I can’t believe stock wine is still so bad with so many games. GTA5 is still unplayable with a keyboard, it just freezes for 5 seconds with every single keypress.
I would just run external games through steam with proton if you have those kinds of issues.
You don’t even have to do that.
Wine managers like Bottles make it extremely easy to slap on whatever fixes and wine variants you might need.
Yeah for sure, thats better in every way, but if you dont want to install another application thats the easiest way.
How do you know what fixes/Wine variants you need?
You google the game to see if smarter people have done the investigating.
If not, you parse logs and errors best you can and try to determine what needs enabling. If you get it working, share it on protondb.
Generally though, enabling “everything” doesn’t come with any direct drawbacks. This is basically what bottles will do when you tell it you want to run a game, which will then allow most games to work fine.
The latest version of GE is generally what you want, too, as wine/GE isn’t supposed to have regressions requiring the use of an older version with some games.
Ah OK, that “everything” solution sounds perfect for me, thanks!
This patch boosts the likelihood of getting that patch to produce similar results by 50%+
<img alt="" src="https://sh.itjust.works/pictrs/image/102d4cf6-e83e-445d-8b38-47bee7fc45f2.png">
Talking about improvements for Wine and Proton then providing no actual data for Proton (which is already using a completely different mehod for syncs - yes the basic wine method sucks) is either stupid or intentionally misleading.
I believe this replaces esync and fsync. IIRC it’s slightly faster and has the benefit of being mainlined.
fsync is mainlined since January 2022 (5.16 iirc).
More recently, from Phoronix:
Support for it already seems to be there in wine, so rather than wait for 6.11 I think I'll just go ahead and apply the patches myself to 6.10-rc7 and see if it makes any difference to the one game I regularly play. If my computer blows up as a result I'll let y'all know.
(Result: None. The versions of wine I have probably need patching or at least configuring in order to use it. In the course of briefly considering trying to work out how to do that, I discovered that the expected improvements are not nearly as dramatic as were suggested compared to what's already most often done in proton (fsync). The main benefit for most of us will be better compatibility, not huge performance gains. Well at least my kernel is ready for it.)
o7
I’d like to see those numbers stacked against modern Proton/Wine-GE solutions focused on gaming, rather than stock Wine
It doesn’t matter much in this case. Once ntsync is working, we all will benefit just the same. (Bottles, Lutris etc need to implement it as well)