Quoting: sonic2kkTo this point, most custom kernels (i.e. Tkg, Zen) already have fsync too! :smile: It is disabled for some games when Proton auto-detects them though, for example Yakuza 0 does not use fsync (uses option `nofsync`), but NieR:Automata does (you can check if a game is using esync/fsync and what options it has by inspecting the Proton log, enabled in launch options with PROTON_LOG=1).

You don't really need fsync anyway, since esync does mostly the same thing without the need for extra kernel interface. But still good to have a more formally correct approach that Wine can finally accept upstream.

View this comment - View article - View full comments

Quoting: ToddLI can't wait to see these changes get added to the Linux kernel and SteamOS because if these numbers are any indication, it sounds like we're in for some awesome gaming experiences on the Steam Deck :smile:

Steam Deck is already using fsync with corresponding kernel API, so it already benefits from better than wineserver approach. I.e. this ntsync isn't going to improve performance over esync or fsync if I understood correctly. It will just make it more formally correct for edge cases.

View this comment - View article - View full comments

Quoting: F.UltraNote that the improvements in the table is vs using the wineserver only so this is not compared with fsync or esync. Looks like the performance is similar to fsync/esync according to the presentation, just that some edge cases like Pulse Events and WaitOnAll now works while they are broken on fsync/esync.

Yeah, for Linux gamers the main benefit of this will be simply that things will finally be upstreamed. Those edge cases will barely matter for anyone.

View this comment - View article - View full comments

That's the consumer shift that needs to happen

Ubisoft should get lost and shift into some garbage dump.

View this comment - View article - View full comments

I don't see much of an improvement in CP2077, but on the other hand, it was pretty bad in the first place. So it might have improved, but not to the point of making it useful there either way. Still, any improvement is welcome.

It should become more useful and make more sense in the future generations of AMD GPUs.

View this comment - View article - View full comments

Quoting: CalinouI don't remember specific font rendering issues when using HDR on any OS (although ClearType/LCD subpixel optimization is undesired on many displays that excel at HDR, such as OLED panels). Thankfully, these are easy to turn off, though I wish this was done automatically when such a display is detected.

That's what I meant. Subpixel layout algorithms for fonts aren't handling all these more weird layoyts of OLEDs, they were made for LCD. Other than that, not sure what you mean by desktops looking bad.

View this comment - View article - View full comments

Quoting: CalinouThere's also the issue with the Windows desktop looking bad on most displays with HDR enabled, but maybe Linux desktops will figure out a way around this like macOS does. In general, macOS probably has the best (i.e. most reliable) HDR implementation right now.

Is it about fonts? It's a pretty messed up situation.

View this comment - View article - View full comments

play most HDR capable games in the Wayland session

I think that still assumes using Gamescope. Hopefully once Wine Wayland gets in shape, it will be possible directly.

View this comment - View article - View full comments

If we only had a few more programmers. It’s the Linux problem

Lol, a few more programmers? What is Epic, some amateur ad-hoc company?

It's complete BS. It's Tim Sweeney problem - he doesn't like Linux gaming.

View this comment - View article - View full comments

Wine Wayland bits are in usable shape there. Can anyone with Sway/wlroots please test if you have the periodic halved refresh rate bug in it?

View this comment - View article - View full comments