NTsync (aka Winesync+Fastsync) - feedback topic

[Iglu47]

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:

  • [21142] Planet Zoo crashes when selecting a friend's avatar
  • [20155] Ubisoft launcher hangs on "looking for patches"
  • [17625] Yakuza 0 hangs on exit
  • [19072] Yakuza 0/Kiwami manual save fails
  • [21194] GTAV hangs or something. This issue: Grand Theft Auto V (271590) ValveSoftware/Proton#37
  • [20444] System Shock: Enhanced Edition hangs on exit

• 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?

1. you need set _winesync="true" in .cfg for linux-tkg, build, install and loading on it
2. when you need set _use_fastsync="true" in .cfg for wine-tkg and build it
3. if you did everything correctly, then when you start the game in the output of the terminal or in the logs will appear
   wine: using fast synchronization.
4. to disable NTsync, set env var 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.

[ms178]

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
Scene 2: 119,4 fps
Scene 3: 102 fps

WINE_DISABLE_FAST_SYNC=1:

Scene 1: 74,0 fps (-1,6 %)
Scene 2: 116,4 fps (-2,5 %)
Scene 3: 101,5 fps (-0,49 %)

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:

❯ inxi -GSC -xx
System:
  Host: klx99 Kernel: 6.1.5-3.2-cachyos-bore-lto arch: x86_64 bits: 64
    compiler: clang v: 16.0.0 Desktop: KDE Plasma v: 5.26.80 tk: Qt v: 5.15.8
    wm: kwin_x11 dm: SDDM Distro: CachyOS
CPU:
  Info: 18-core model: Intel Xeon E5-2696 v3 bits: 64 type: MT MCP
    arch: Haswell rev: 2 cache: L1: 1.1 MiB L2: 4.5 MiB L3: 45 MiB
  Speed (MHz): avg: 2312 high: 3790 min/max: 1200/2301 boost: enabled cores:
    1: 2301 2: 2301 3: 2301 4: 2301 5: 2301 6: 2301 7: 2301 8: 2301 9: 2301
    10: 2301 11: 2301 12: 2301 13: 1241 14: 2301 15: 2301 16: 2301 17: 2301
    18: 2301 19: 2301 20: 2301 21: 2301 22: 2301 23: 3790 24: 2301 25: 2301
    26: 2301 27: 2301 28: 2301 29: 2301 30: 2301 31: 2301 32: 2301 33: 2301
    34: 2301 35: 2301 36: 2301 bogomips: 165744
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: AMD Vega 10 XL/XT [Radeon RX 56/64] vendor: Micro-Star MSI
    driver: amdgpu v: kernel arch: GCN-5 pcie: speed: 8 GT/s lanes: 16 ports:
    active: DP-3 empty: DP-1,DP-2,HDMI-A-1 bus-ID: 05:00.0 chip-ID: 1002:687f
  Display: x11 server: X.Org v: 21.1.99 with: Xwayland v: 22.1.7
    compositor: kwin_x11 driver: X: loaded: amdgpu unloaded: modesetting
    alternate: fbdev,vesa dri: radeonsi gpu: amdgpu display-ID: :0 screens: 1
  Screen-1: 0 s-res: 2560x1440 s-dpi: 96
  Monitor-1: DP-3 mapped: DisplayPort-2 model: HP X27q res: 2560x1440
    dpi: 109 diag: 685mm (27")
  API: OpenGL v: 4.6 Mesa 23.1.0-devel (git-267dd1f4d5) renderer: AMD
    Radeon RX Vega (vega10 LLVM 16.0.0 DRM 3.49 6.1.5-3.2-cachyos-bore-lto)
    direct render: Yes

[ms178]

Company of Heroes 2 - WQHD, Higher preset

With NTSync (2nd run):

Min: 56,00 fps
Avg: 79,84 fps
Max: 127,87 fps

WINE_DISABLE_FAST_SYNC=1:

Min: 56,99 fps (+1,7 %)
Avg: 80,44 fps (+0,75 %)
Max: 129,22 fps (+1,06 %)

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?

[Tk-Glitch]

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 WINE_DISABLE_FAST_SYNC=1 runs are with server-side sync, the difference should be much higher if you're CPU bound (>20% is quite common). If that's with fsync it's in line with what is to be expected from winesync, which is pretty much equal perf to fsync.

[Iglu47]

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:

ntsync:

UPD. another run I made mangolog https://flightlessmango.com/games/26979/logs/3576

please make sure the terminal output or log show wine: using fast synchronization. before posting resault here (we want the test results to be valid)

[Tk-Glitch]

Those results are making much more sense @Iglu47 . Thanks.

[ms178]

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. .

[Tk-Glitch]

@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 winesync-dkms and winesync-udev-rule packages to begin with, and then either manually loading the module or adding it to your modules-load.d for it to be loaded on boot.

You didn't confirm you were seeing wine: using fast synchronization. in your wine output which would tell us if your results are indeed valid and everything was done correctly (either by you or the CachyOS maintainers), or not. You are talking with devs here, please try to understand we're expecting you to follow our guidelines if you participate in testing.

[ms178]

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.
winesync-dkms / winesync-udev-rule were also installed. I assume ptr1337 handled all the neccesary patches, as he has seen NTSync working correctly with his binaries on other machines. The modules-load.d info is new to me though, I am deferring to prt1337 if that was handled automatically with his packages. If not, that could be a source for the deviation in the numbers. On the other hand, with a 1080Ti, the better result from Iglu47 with 140+ fps is also not too distant from mine with 119,4 fps and my Vega 56.

[FuzzyQuils]

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!)

[Iglu47]

[20155] Ubisoft launcher hangs on "looking for patches"

Still present with NTsync for me. Using "wineserver sync" helps as workaround.

[LethalManBoob]

i get hangs on ea's new game app

[csutcliff]

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.

[csutcliff]

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.

[ptr1337]

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.
Also you can disable NTsync/Winesync with your current running wine/proton with:
WINE_DISABLE_FAST_SYNC=1

[LethalManBoob]

winesync tkg is gone from aur

[csutcliff]

winesync tkg is gone from aur

https://aur.archlinux.org/packages/winesync-dkms &
https://aur.archlinux.org/packages/winesync-udev-rule

works fine

[LethalManBoob]

There was a specific prebuild protonified wine version of tkg that supported winesync
edit: spoke to ptr 1337 this was due to tkg making changes that made the cachyos prebuilds unusable

[shmerl]

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.

[rlees85]

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.

[An-Eagle]

[20155] Ubisoft launcher hangs on "looking for patches"

Still present with NTsync for me. Using "wineserver sync" helps as workaround.

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.

[shmerl]

Just a follow up. Any recommended way to use Winesync now over upstream kernel and wine? Various repos are quite outdated to apply things.

[FuzzyQuils]

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.

[shmerl]

Recent build of wine-tkg with fastsync enabled in the config

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?

[shmerl]

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.

[Iglu47]

@shmerl the status has not changed.
Important Information: Reports are needed to ensure that NTsync/Winesync does not introduce any new issues compared to Esync.

[ptr1337]

@shmerl the status has not changed. Important Information: Reports are needed to ensure that NTsync/Winesync does not introduce any new issues compared to Esync.

Generally a rebase against proton 8 would be very interesting for many users, i think.

[Iglu47]

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

[csutcliff]

Is there anyone working on or planning on re-basing against the current wine master since it broke?

[daktras420]

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.

[totolgueimer]

Though note that it's not generally applicable and I don't know whether it's even applicable in regular GW2 gameplay.

Garden Warfare 2?

[Atemu]

If you'd bothered to read my initial post, you'd know it's Guild Wars 2.

[shmerl]

Still no ack on the new patchset. May be maintainers are on vacation. Let's hope it's approved early next year.

[nokia8801]

I assume we need Linux 6.13 to build now, because of the new patch? Cause it doesn't build with 6.12.4 on Arch Linux.

../wine-git/dlls/ntdll/unix/sync.c: In function ‘linux_release_semaphore_obj’:
../wine-git/dlls/ntdll/unix/sync.c:647:23: error: ‘NTSYNC_IOC_SEM_RELEASE’ undeclared (first use in this function); did you mean ‘NTSYNC_IOC_SEM_READ’?
  647 |     ret = ioctl( obj, NTSYNC_IOC_SEM_RELEASE, &count );
      |                       ^~~~~~~~~~~~~~~~~~~~~~
      |                       NTSYNC_IOC_SEM_READ
../wine-git/dlls/ntdll/unix/sync.c:647:23: note: each undeclared identifier is reported only once for each function it appears in
gcc -m64 -c -o dlls/ntdll/unix/thread.o ../wine-git/dlls/ntdll/unix/thread.c -Idlls/ntdll -I../wine-git/dlls/ntdll -Iinclude \
  -I../wine-git/include -D__WINESRC__ -D_NTSYSTEM_ -D_ACRTIMP= -DWINBASEAPI= -DWINE_UNIX_LIB -Wall \
  -pipe -fcf-protection=none -fvisibility=hidden -fno-stack-protector -fno-strict-aliasing \
  -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Winit-self -Wlogical-op \
  -Wno-packed-not-aligned -Wpointer-arith -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \
  -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wno-misleading-indentation -fPIC \
  -fasynchronous-unwind-tables -march=rocketlake -mtune=rocketlake -O2 -ftree-vectorize -Wno-error=implicit-function-declaration -Wno-error=incompatible-pointer-types
make: *** [Makefile:148007: dlls/ntdll/unix/sync.o] Error 1
make: *** Waiting for unfinished jobs....
  -> Removed BIG_UGLY_FROGMINER - Ribbit
  -> Removed Proton-tkg token - Valve Ribbit
  -> exit cleanup done
==> Removing installed dependencies...

[Atemu]

You need the appropriate Linux header; that's what this error is about. WINE is userspace.

[Artewar67]

I just added ntsync7 support for ntsync5 v7. But then I realized that it is currently only available in linux-cachyos 6.12.6 and maybe in other custom kernels, in ntsync5-dkms from AUR and linux-zen still ntsync5 v6. So now I have created a pull request: #1345

[nokia8801]

I was using this with all three ntsync packages from the AUR with normal Arch linux kernel. AUR maintainer says he will wait? I don't get it? Will I still be able to use it with normal linux kernel when everything is updated? Or will I have to wait for 6.13?

[Artewar67]

@nokia8801 With this pull request you will now be able to use ntsync5 again. I just added ntsync7 as a separate version that can be used if you set _use_ntsync=“ntsync7” in customization.cfg

[Atemu]

@nokia8801 you need:

1. A kernel with the ntsync kernel module patches applied. They're not mainline yet.
2. The Linux kernel headers built from the same kernel source with patches applied in order to produce the ntsync.h
3. WINE with the ntsync patches applied that match your kernel's iteration of the ntsync API

Additionally, you will likely need to chmod the /dev/ntsync device as it's root-only by default.

[nokia8801]

@nokia8801 you need:

1. A kernel with the ntsync kernel module patches applied. They're _not_ mainline yet.

2. The Linux kernel headers built from the same kernel source with patches applied in order to produce the `ntsync.h`

3. WINE with the ntsync patches applied that match your kernel's iteration of the ntsync API

Additionally, you will likely need to chmod the /dev/ntsync device as it's root-only by default.

As I said, I already know all this and have been using it like this with no issues for the past month. Using the regular linux kernel from Arch core repository, with three ntsync packages installed from the AUR and wine-tkg-git compiled with ntsync support. I never had to chmod /dev/ntsync btw.

However, after commit 0638ad0, it did not build with Linux 6.12.4-arch1-1 and current ntsync packages from the AUR. It showed that error I posted above.

Maintainer of the AUR packages says this:

I think I should refrain from updating until the new code appears in linux-zen. I could be wrong, but that's where most people are probably getting the module from in Arch. The headers go in-hand with the module, and linux-api-headers includes the BROKEN header from mainline linux which doesn't work anyways, so updating this without the correct module in place for linux-zen will cause issues as header and module will be incompatible with each other.

I don't use linux-zen so I was a bit confused. But thanks to @Artewar67 with commit 41f7e24, it now works again and I updated to 10.0-rc3. NTsync works as usual.

[Atemu]

Using the regular linux kernel from Arch core repository

If you're using the regular Arch kernel, you have no ntsync support whatsoever. There will be no ntsync kernel module or device.

with three ntsync packages installed from the AUR

WDYM by "ntsync packages"? There's no such thing. There's only patches for the kernel and WINE.

However, after commit 0638ad0, it did not build with Linux 6.12.4-arch1-1 and current ntsync packages from the AUR. It showed that error I posted above.

Looking closer at the error again, it's due to an ABI mismatch, not missing headers. Ensure your kernel patches aswell as the headers generated from the patched kernel are from the same patch revision of ntsync as the WINE patches. There was an ABI break recently. Mismatched versions will not work.

[nokia8801]

What you mean there is no NTsync support? It works when these packages are installed, using the regular linux kernel as I said. Linux 6.12.4-arch1-1. Unless I'm mistaken.

ntsync-dkms
ntsync-header
ntsync-common

Lutris log:

lutris-wrapper: Max Payne 3
Started initial process 229326 from gamemoderun mangohud /usr/bin/wine /home/nokia8801/Games/Max Payne 3 - Complete Edition/Max Payne 3/MaxPayne3.exe
Start monitoring process.
wine: using fast synchronization.
MESA: warning: Support for this platform is experimental with Xe KMD, bug reports may be ignored.

Screenshot:

[OrionMoonclaw]

Tried this with Resonite just now (also arch with the dkms module) but it seems like it has some major instability. It either freezes during loading, gets stuck on the loading screen, or launches with missing textures or a broken (invisible) dash.

[Atemu]

ntsync-dkms
ntsync-header
ntsync-common

Ah, I see. Building the module out-of-tree also works ig.

This is a single package which provides multiple packages that each provide (in order) kernel module, kernel headers and udev rules.
The dkms one is what provides your kernel module and the "common" one provides a handy udev rule so that you don't have to chmod the ntsync device.

What causes your error is that the version of the patch this package is based upon must be compatible with the WINE patches; the ABI has changed recently.

Incompatible versions will not compile (with your error) and pre-compiled versions will not work correctly.

If you want to use the latest ntsync patches for WINE, you need to update this package to the newest kernel patches. You could probably just do that yourself.

[Patroklos99]

Are there anything else left from Elizabeths side or everything that's to implement has been submitted in v7?

I'll be testing soon. Currently in openSUSE TW. Any specific distro you guys recommend to make the testing easier?

[Username404-59]

I'll be testing soon. Currently in openSUSE TW. Any specific distro you guys recommend to make the testing easier?

Latest CachyOS has NTSync v7 support

[BlueCyro]

@Atemu I built your fork last night with the help of a friend, but when I launch games with it, all I get is fsync. I'm using the out-of-tree modules: ntsync-dkms, ntsync-header, and ntsync-common.

/proc/modules shows the ntsync device with a chmod of 644, owned by root (tried 777 for shits n' giggles, no luck). Afaik the kernel module is loaded. Does it matter that I compiled it without it modprobed?

Or is there perhaps a compilation flag or launch argument I need in order to launch with ntsync support? Using mainline kernel Linux 6.12.4-arch1-1

[Atemu]

If the device is present and your user has rw access, it should work.

Have you disabled fsync and esync? Those currently take precedence.

[loathingKernel]

Have you disabled fsync and esync? Those currently take precedence.

Do they take precedence or wine is using both synchronization methods? In your rebase I don't see anything guarding against enabling ntsync when either fsync or esync are enabled.

[Atemu]

Good question; I merely did a dumb cherry-pick of the patches and resolved conflicts. It only prints one using: in the log, so I assume it's only using one or the other.

It may very well be the case that my rebase is wrong or bad in some way.

[loathingKernel]

I am asking because my rebase disables the other two when ntsync is enabled, but suffers from an issue with Unity games hanging. I was more interested in making them run with fsync/esync disabled that it didn't occur to me to test with allowing either of them to stay enabled to see if it "fixes" the issue. It's not a solution but it could be an interim hack.

[Artewar67]

Are you guys talking about ntsync5 port on valve proton?

I was trying to port ntsync and also encountered the unity problem. I solved it by replacing NtWaitForSingleObject with server_wait_for_object in dlls/ntdll/unix/thread.c in NtSuspendThread funtion

    {
        NtWaitForSingleObject( wait_handle, FALSE, NULL );

        SERVER_START_REQ( suspend_thread )
        {
            req->handle = wine_server_obj_handle( handle );
            req->waited_handle = wine_server_obj_handle( wait_handle );
            ret = wine_server_call( req );
        }
        SERVER_END_REQ;

[Atemu]

I am asking because my rebase disables the other two when ntsync is enabled, but suffers from an issue with Unity games hanging. I was more interested in making them run with fsync/esync disabled that it didn't occur to me to test with allowing either of them to stay enabled to see if it "fixes" the issue. It's not a solution but it could be an interim hack.

Hm, I don't think it'd be good to have both enabled. I'd actually considered removing esync/fsync support entirely but it touches a dozen places because C doesn't have default values for structs and a revert wouldn't be possible cleanly.

I actually also experience a hang in the Planetside 2 launcher which is an old CEF. I actually wrote an email to Elizabeth and she said she doesn't have the bandwidth to look into random rebases of her patches which is fair. She told be to try to repro with regular WINE with her ntsync patches but I haven't gotten around to doing that yet. I'd recommend you do that. If it works with her WINE branch but not your rebase (or mine), we dun goofed up ;)

[loathingKernel]

She told be to try to repro with regular WINE with her ntsync patches but I haven't gotten around to doing that yet. I'd recommend you do that.

I've been using ntsync on mainline wine since 9.8 and I haven't encountered issues with Unity games there or later rebases on top of mainline wine, so I think it is safe to assume that whatever issue this is it's in conjunction with esync/fsync on Proton. I have not encountered the old CEF issue on mainline wine either, or maybe I didn't because there wasn't one, so it's inconclusive in that regard.

In the meantime I will queue a rebuild following @Artewar67 's fix and see how that goes.

[loathingKernel]

@Artewar67 You solution indeed works and it allowed for Unity games to run with ntsync.

FWIW for unrelated reasons I had to use my ntsync7 rebase, the complete patchset I used can be found here CachyOS/wine-cachyos@cachyos-9.0-20241206-base...cachyos_staging/ntsync7

I have also updated the AUR ntsync package since linux-zen-6.12.6 is in testing and soon to be moved to stable.

[Patroklos99]

@loathingKernel so how's the experience any improvements compared to default syncs?

[nokia8801]

Does NTsync even work with Proton? I've been happily using it with Wine with Lutris for the past month, but also want to utilize it with Proton on Steam. Do I need a different patch or repository for it? Or is just a matter of compiling proton-tkg with ntsync=true?

[Atemu]

You need to rebase the WINE patches ontop of Proton. This involves solving quite a few conflicts as Proton includes esync/fsync support which hooks into the same sort of places in the code base.

@loathingKernel and I apparently did it independently but both have discovered issues that are likely caused by the integration into Proton.

[nokia8801]

@nokia8801 With this pull request you will now be able to use ntsync5 again. I just added ntsync7 as a separate version that can be used if you set _use_ntsync=“ntsync7” in customization.cfg

When it's set to _use_ntsync=“ntsync7” and all others false, the resulting Wine version is displayed as ( TkG Staging Esync NTsync ) in MangoHud, instead of ( TkG Staging NTsync ) like before.

NTsync still works, just wanted to point out this little bug.

Edit: It's fixed with the latest revert and just using _use_ntsync=true.