NTsync (aka Winesync+Fastsync) - feedback topic #936
Comments
|
I've got some numbers for you from the in-game-benchmark in Total War: Troy in 1080p / Ultra. With NTSync: Scene 1: 75,2 fps WINE_DISABLE_FAST_SYNC=1: Scene 1: 74,0 fps (-1,6 %) Analysis: Scene 2 is the most CPU-bound of the three. As you see, there is quite a pronounced impact from the change. My test system: |
|
Company of Heroes 2 - WQHD, Higher preset With NTSync (2nd run): Min: 56,00 fps WINE_DISABLE_FAST_SYNC=1: Min: 56,99 fps (+1,7 %) Notes: There is a performance regression with NTSync in this older game. The first run with NTSync showed even worse numbers (77 fps avg) - but that might have been due to the shader compilation, hence I took the numbers from the second run which did show some improvements. I wouldn't read too much into this result as it is still in the range of normal deviation in this benchmark. Maybe still something worth to investigate? |
With only 2 runs it's hard to say if it's more than margin of error considering such minuscule differences. If the average on 10 runs leads to a similar gap, then that could be considered as an actual perf drop. Now and that being said, if the |
|
thanks for trying to look into this. I have access to the EGS-version of A Total War Saga: Troy so I did a couple of tests with "campaign_benchmark" at Ultra preset settings - there seems to be a difference between regular wineserver-sync and ntsync at least. screenshots of the in-game "campaign_benchmark" result
server-side sync: UPD. another run I made mangolog https://flightlessmango.com/games/26979/logs/3576 please make sure the terminal output or log show |
|
Those results are making much more sense @Iglu47 . Thanks. |
|
I have no control over the build process, I simply used the proton-winesync binary packages ptr1337 provided in CachyOS for testers. That means by deduction that my numbers are highly likely just as valid as Iglu47's, as I've used the defaults even if they look different. Our hardware and software setup is very different after all. I will leave more testing to others as I spend enough of my time with this experimental version that has other issues - even if Tk-Glitch considers these expected behavior. . |
|
@ms178 The proton build isn't enough for NTsync to work. Unless @ptr1337 added similar patches and handling to what we're doing in linux-tkg, you would need both You didn't confirm you were seeing |
|
Please have mercy with me, I am not a programmer and just wanted to help you guys. :) Admittedly I had missed that crucial part of the process. |
|
Hello, your resident Overwatch player reporting in! Soon as I have time I can get performance numbers vs server sync but I am glad to report Battle.net crashing wineserver in some cases with fsync doesn’t happen with winesync. (A reliable repro for the fsync issue is to also run Battle.net via Feral’s Gamemode with fsync enabled, such thing doesn’t happen using Winesync!) |
Still present with NTsync for me. Using "wineserver sync" helps as workaround. |
|
i get hangs on ea's new game app |
|
Battle.net client struggles with fsync (fails to launch 1/2 the time). So far it hasn't had an issue starting with winesync. In-game performance (WoW) appears to be the same or better than fsync but being an MMO it is fairly subjective. |
|
Again not a perfect comparison as it's protonified vanilla wine vs actual proton with valve wine but Hogwarts Legacies is running better (10-15 fps at 4k ultra no RT) with fastsync than fsync and hasn't crashed on me yet which was frequently happening on load screens. |
You can also compile a fsync protonfied vanilla wine, then you would have a better comparison. |
|
winesync tkg is gone from aur |
https://aur.archlinux.org/packages/winesync-dkms & works fine |
|
There was a specific prebuild protonified wine version of tkg that supported winesync |
|
Is there some instruction how to build and test winesync? And what's the current status of it? A side question, I recently encountered huge performance improvement in the Witcher 3 (DX12 mode) and Cyberpunk 2077 when Wine-esync is used. I wanted to compare it to Wine+fsync. What is a good way to apply fsync patches to upstream Wine? I didn't find it in Wine-staging and it's not clear how to apply them from other sources. |
|
Another report for Battle.net working nicely with winesync. On both esync and fsync it would not launch half the time or cause wineserver to coredump sometimes taking the whole system with it. I've been playing StarCraft 2 and Overwatch 2 - both used to work with fsync anyway - with winesync. No problems. Performance in StarCraft 2 is better but it could be any number of reasons since wine-tkg (my custom build of)/wine-ge-custom are very different things. |
Not completely related to this thread, but the crypt32 dll isntalled through winetricks allows to get through this error in my experience, and has for a few other users I have helped in the past. |
|
Just a follow up. Any recommended way to use Winesync now over upstream kernel and wine? Various repos are quite outdated to apply things. |
The winesync-dkms module + a recent build of wine-tkg with fastsync enabled in the config. That's generally what I do. For Proton, it's a bit trickier, I've been working on a valve tree patchset for that. |
I tried playing around with that, but couldn't figure out how to apply only that on top of upstream Wine. wine-tgk has a ton of stuff and is a bit cumbersome to configure. No matter what I tried, it seemed to pull some extra stuff that I didn't want. It would be nice to have something like wine-staging patchset for it that is easy to apply to upstream Wine. And which repo has an up to date dkms module for winesync? |
|
What's the current state of this in general? I.e. is it close to getting upstream or more data is needed? Are there any blockers? Not sure where / how to check the status, so asking here. |
|
@shmerl the status has not changed. |
Generally a rebase against proton 8 would be very interesting for many users, i think. |
porting to wine-valve tree and availability of wenesync module. I'll try to find the time and do something about it |
|
Is there anyone working on or planning on re-basing against the current wine master since it broke? |
|
thank you Iglu47 i was planning on doing wine build this week using your patchset and the wine-valve tree as well as proton for steam with the ntsync patches if its doable what reversion or current tree version are your patches compatible with ei. wine-protonified, or wine-protontified bleeding edge, same for steams proton which build is most compatible? for now since i have dxvk gasync installed via aur with arch will try it using system dxvk and see if it all works till and if the developer of the new dxvk patch files work is included into the frogging family of patches. |
|
Man, there really needs to be an easier way to get Valve trees to compile with NTsync and WoW64, or somehow use Wine with those features to play Steam games. Performance is abysmal with Proton using fsync and 32-bit libraries. I'm gonna post some benchmarks later but it's bad in my case. Intel Arc A750 GPU, could be a factor. But it for sure benefits from NTsync and WoW64. I really don't need nor want Proton. Wine is enough for me. But can't get Steam to use Wine. Anyone got a solution? |
|
Things need to finally get upstream. Looks like it's moving now! |
|
How does the work flow works for MR in the kernel? |
It is likely going into 6.14 - but it could be also delayed to 6.15, since patches normally need to be around 6 weeks in the linux-next tree. |
|
Testing tree looks like something relatively recent: https://lwn.net/ml/all/ZxZ8MStt4e8JXeJb@sashalap/ I suppose if it succeeds (i.e. testing won't reveal any regressions and issues), it will land in the currently opened merge window. |
|
Yeah, but isn't this assuming Valve will immediately adopt in their trees and start using it? I have a feeling they'll keep using fsync for the foreseeable future. Unless it becomes the same as the Wayland driver, where it can be configured with Proton-tkg but still not used by Valve? If that's the case, I don't really care what Valve does. Wine having it is more important if Proton can use it with this repo. In other news, I still would like to have WoW64 too... Can't I have Proton without Wine? It says "NOLIB32 detected, not allowed with Valve trees" or something like that, even when I choose "Wine tree (except breakage)". |
|
Not sure about Valve, but upstream Wine will probably merge those changes fast enough after the kernel gets them. Personally I'm using upstream winewayland + esync from staging at present, but switching to ntsync would be better. And yeah, I'm using the new wow64 too, but it still can't handle 32-bit OpenGL. |
Well actually you can build proton-tkg with normal wine+ntsync, or try to patch valve wine with loathingKernel's try at a port However do note that wow64, which you want to use too, breaks some anticheats and I don't think it improves performance |
I'll try that PKGBUILD, thanks. Can I get a source on WoW64 breaking anti-cheat? Which anti-cheats? VAC? Not being dismissive, really curious. Don't want to risk anything. I'd like to read more about it. Plutonium's anti-cheat and PunkBuster for Battlefield 4 work in my case. No issues. For me, playing Black Ops 1, I get around avg 80 FPS with Fsync and no WoW64. But the performance is terrible as it goes down to 30 FPS and up to 250 FPS depending on where you're looking. GPU speed rarely goes above 1000MHz for some reason. Don't know why that is happening. Also there are audio crackling issues. Gunfire sounds are broken.
But playing Black Ops 1 with the Plutonium Launcher, using NTsync and WoW64, I get over 300 FPS, sometimes over 400 FPS. It's so smooth, no stutters or weird bugs. No audio issues either. I normally lock it 230 FPS on my 240Hz VRR monitor to get the best experience. It never falls below 230FPS with this setup.
Kinda starting to hate Proton, ngl... Gonna try these Wine combinations as well, to see if NTsync or WoW64 is the feature that makes all this possible, or both of them combined
Wine and Proton both using the Wayland driver btw, as pictured above. Edit: Ok did some more testing with Proton, seems related to Steam Runtime, as running steam-native-runtime with system libraries improved performance a bit. Still getting trash performance and audio issues, FPS depends on where I look, but it's much better than before, around 140-200 FPS. |
EasyAntiCheat on star citizen at least |
how do i build wine tkg with wow64? |
Under |
|
thanks |
|
Does anyone know if NTSync (the version going into 6.14) has a DKMS version? EDIT: Found the AUR PKGBUILD for it, looks like it's also using the latest patchset. |
|
does anyone have a tip? i try to create with “none” and ntsync and it always fails in the patch application. if i try it with staging it works, but i have problems with starcitizen. |
If it's just staging causing issues & not ntsync itself, you can go ask for help in the LUG discord |
|
Either way, it makes sense to compile a wine without staging but with ntsync. |
|
NTSync doesn't seem to work with CEG games, I cannot escape blackscreens on Saints Row The Third, COD: Black Ops 2 just gets stuck launching with no game showing |
Black Ops 2 works for me with NTsync. No black screens. |
|
Kernel changes merged! 🎉 https://gitlab.com/linux-kernel/linux/-/commits/master/drivers/misc/ntsync.c |
|
Does wine have a commit ready to be merged once 6.14 is out? |
|
Not sure how soon Wine will merge it. I assume it will be able to handle fallback to esync in case of older kernels? We'll have to wait and see. My guess is that eventually it will be default everywhere, but it will take time. |
Upstream WINE doesn't have esync. That's been in staging for forever because it's not a correct implementation. I assume ntsync will be merged at some point and become the new preferred method with the current (slow) wineserver IPC based approach being the fallback. Proton will likely have to implement fallbacks to esync/fsync. |
|
Obviously those who need it now aren't using upstream wine already. What I'm talking about is having esync and ntsync both (like in staging for example), to be able to have fallback for kernels that don't have it yet. |
|
I don't think we'll see NTsync in Proton or SteamOS anytime soon. AFAIK, Valve uses a heavily modified 6.5 kernel base for SteamOS. Yes, they jumped on fsync asap, even when it wasn't upstreamable, but they still haven't built Wine using Also, Valve could have done to NTsync what they did to Fsync, which is implement it before it was accepted, like what we've been doing here for the past year or so. They'll probably wait, especially if they decide it's not necessarily needed when they already have fsync. We'll see if Proton 10 manages to have both Wayland and NTsync. I'm crossing my fingers. I'd love to be proven wrong though. From my testing, NTsync isn't just an improvement over normal server side Winesync, it's also a somewhat big, relatively speaking, improvement over Fsync as well. So Valve should have a big incentive to jump on it asap like they did with Fsync, but they haven't yet. Hopefully it being in Linux 6.14 and also Wine merge request for it being accepted very soon, means Valve can use it immediately. |
Maybe. But maybe not. |
Well, one could say this is a bad analogy, because Wayland, even with NVIDIA since 2021 (GBM) and explicit sync since last year, Intel, AMD, everything has worked perfectly fine for me. VRR, scaling, performance, inputs, latency, hardware video acceleration, direct scanout, etc and much more. It's just a better, more native experience. Valve has conflicting interests when it comes to Wayland imo. On one hand, native Wayland would benefit and accelerate HDR protocol adoptions. On the other hand, they've already poured so much into Gamescope and would probably prefer to keep that alive, especially considering SteamOS's current targets which are handhelds. Not to mention the But I won't go into more detail, as this is an issue for NTsync. Wayland "just works". |
No, it isn't. Illogical fanatical tirades that endlessly reiterate the sermons have little to do with reality. Be it Wayland cult or Rust cult. But I see the acolytes have already arrived with torches.
Good thing I wasn't using Nvidia GPUs for like 20 years now and wasn't keen on transitioning to Wayland to just create problems and get more broken functions for no reason. So "it just works for me" because it was never broken after AMD got their shit together with the drivers.
And everything was working fine for me before the cult have decided to create new problems instead of solutions to existing ones. There is nothing "better" about it, not a single tangible real benefit, only brainwashing to glorify placebos ("It's just a better, more native experience"... seriously? what does it even mean in numbers?) and aggressively push that trash into everything.
I'm amazed that there are such rational people at Valve. Unfortunately, the cult will push its trash into everyone's throats (just like systemd, and most of original FOSS source repos, that was basically taken over by Microsoft in its newest round of EEE takeover strategy with its Red Hat pals waving their tails not far behind), so we will have to deal with it eventually. Which is why there is hope that Valve will make a rational decision once again.
It really isn't. You even just confirmed that "HDR" (or any colour correction) is still absent after >10 years of pushing the half-baked trash. Which is just one of broken core functions. Once again, it only creates problems, it doesn't solve a single thing for me. I'm not you, stop projecting your weird faith on my life. It's like if some parents would randomly decide to snuff out their healthy newborn child and get a disabled abandoned one from orphanage to satisfy some twisted desire of psedomorality-based self-aggrandizement. Or a meme of house burning down with "this is fine" caption - massive super-cope. |
|
My dude, you are missing the point, my original statement:
means just that, nothing more, nothing less. Proton's Wine isn't built with Wayland support. I never said Proton should actually use Wayland, or asked why it doesn't use Wayland, for all intents and purposes it could've been locked behind a And winewayland.drv has been upstreamed since back then, unlike Fsync or NTsync. So I that's why I made a comparison. NTsync will either get the Fsync treatment, or Wayland treatment. I don't know which will happen, only time will tell. Don't know why you're taking the discussion elsewhere. I think you'll fit right in on platforms like r/linux and Phoronix Forums, lots of Wayland critics there, just like yourself. Let me guess, you don't like GNOME too? Anyways, please keep the discussion to NTsync. Here, see for yourself. ValveSoftware/Proton#4638 |
|
So far it's not clear what will happen when Wine side of changes will be merged. I.e. what they'll do with esync patches. I'm personally not using Proton, so all I care about is a smooth switch from esync to ntsync, but for that to happen esync would need to be usable for some time after Wine merges nstsync, since that will likely happen before kernel 6.14 is out. Also, for the reference I've been using winewayland for several months already and it works very well, so keep this annoyance at Wayland out. |
and others
NTsync (title not approved) is more "Correctness" and "Robustness" alternative implementation of synchronization primitives in Wine from Zebediah Figura (the author of "Esync" and "Fsync").
This requires changes on the Wine side (usually patches are called - fastsync ) and corresponding changes on the kernel side (implemented as a kernel module - winesync. Unlike Fsync, the winesync functionality cannot be used anywhere except Wine).
More details about what problem NTsync solves and what is "implementation of synchronization primitives in Wine" can be found here: https://lkml.org/lkml/2021/1/17/312 and here: sync2022.pdf
Some plans and wishes for tests from @zfigura:
Find or get good, convincing data vs server sync. Benchmarks of esync are hard to find and a lot of them are not exactly very convincing (on the order of 50 -> 54 FPS).
Test ntsync with applications that break with fsync or esync:
Add this information to the document. I intend to submit this upstream along with the cover letter.
Submit kernel patches upstream.
CALL FOR TESTS: anyone who can test games from the "breaks with esync/fsync" list, that would be quite appreciated. Note there's a lot more that break simply because of PulseEvent(), and we've had a couple tested already and they work so I'm not worried about those. All of the above break because of subtler timing problems and I'd like to see if they work with ntsync.
ALSO CALL FOR TESTS: I need good, convincing data comparing winesync vs server side sync. I don't have application names because in the 3-4 years since I wrote esync I've completely forgotten what the most important applications even are.
How to get NTsync working on TkG builds?
_winesync="true"in .cfg for linux-tkg, build, install and loading on it_use_fastsync="true"in .cfg for wine-tkg and build itwine: using fast synchronization.WINE_DISABLE_FAST_SYNC=1.*Please don't post conflicts with other patches, versions of Wine, or other things related to building or installing kernel or Wine in THIS thread - this is a place intended for developers and other players to see other people's NTsync test results and determine if there are any significant performance deviations (both up and down) compared to wineserver-sync, esync, fsync. And any issues are saved or added compared to esync/fsync/wineserver-sync only.
The text was updated successfully, but these errors were encountered: