Seems like the upcoming Linux kernel 6.14 release is going to be a nice one for gamers on Linux / Steam Deck, as the NTSYNC code has now been properly merged in ready.
Developer Greg Kroah-Hartman sent in the request, which was then accepted by Linus Torvalds. Amongst other things it includes the completed and enabled NTSYNC driver. As a refresher: Proton already has the likes of Esync and Fsync, which are ways to match certain behaviour expected by Windows games. This new NTSYNC driver directly in the Linux kernel should be more accurate and give better compatibility overall.
For plain Wine there's a big performance benefit, but for Valve's Proton it will mostly be around the same. However, we may see some better compatibility in certain games. The performance difference versus plain Wine that were shown off before across different systems:
Game | Upstream | ntsync | improvement |
Anger Foot | 69 | 99 | 43% |
Call of Juarez | 99.8 | 224.1 | 125% |
Dirt 3 | 110.6 | 860.7 | 678% |
Forza Horizon 5 | 108 | 160 | 48% |
Lara Croft: Temple of Osiris | 141 | 326 | 131% |
Metro 2033 | 164.4 | 199.2 | 21% |
Resident Evil 2 | 26 | 77 | 196% |
The Crew | 26 | 51 | 96% |
Tiny Tina's Wonderlands | 130 | 360 | 177% |
Total War Saga: Troy | 109 | 146 | 34% |
Nice to see it finally happen! Ready for the expansion of SteamOS to more devices.
The most unstable version of SteamOS seems to be at Kernel 6.8 and when you consider the fact that Proton already has the alternatives patched in, there seems to be some misunderstandingIt's worse. I checked it. The current Steam Deck Kernel seems to be derived from a 6.5 Release.
In the Preview and Beta Channels, it's listed as 6.5.0-valve23-1-neptune-65-g385b5e207ae2.
––
I think you did miss the most unstable SteamOS channel that is (probably) only visible in dev mode. The channel names are a confusing mess in the German version, so I'm not sure what it is named.
Last edited by Klaas on 28 Jan 2025 at 12:16 pm UTC
This new approach should emulate the correct behaviour and therefore is supposed to be able to become a part of wine. The previous attempts (esync/fsync) do not emulate the correct behaviour in two (?) situations.
I might be blind and dumb as usual, but are there any benchmarks out there comparing this to e/fsync instead of vanilla Wine? I'm far more curious about those numbers.
Fsync don't have a big performance difference against wine, so nsync gonna have a better performance than both wine and proton, you can see that on Brodie video
Last edited by Villian on 28 Jan 2025 at 7:54 pm UTC
See more from me