The NTSYNC Driver For Wine/Proton Is "Broken" For Linux 6.10

[shmerl]

I don't know the details but if this really has advantages over the existing sync primitives, maybe it could be used for other things beyond games (async language runtimes, databases etc come to mind).

It's only useful for emulating quirky Windows API. You don't need it for anything else.

[ssokolow]

It's only useful for emulating quirky Windows API. You don't need it for anything else.

Given the original ntsync announcement, I'm not sure I'd be so quick to be so autoritative about that. It's possible something useful for native Linux apps might shake out of it.

"The Wine project emulates the Windows API in user space. One particular part of that API, namely the NT synchronization primitives, have historically been implemented via RPC to a dedicated "kernel" process. However, more recent applications use these APIs more strenuously, and the overhead of RPC has become a bottleneck.

The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness. Certain operations, such as NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require direct control over the underlying wait queue, and implementing a wait queue sufficiently robust for Wine in user space is not possible. This proposed driver, therefore, implements the problematic interfaces directly in the Linux kernel."

[shmerl]

Given the original ntsync announcement, I'm not sure I'd be so quick to be so autoritative about that. It's possible something useful for native Linux apps might shake out of it.

There is a more detailed talk that goes into it. Basically, the edge cases that require that (pulse event and wait for all abstractions) are not something you should be using even on Windows. They are some quirks that exist only due to backwards compatibility needs there and Wine has to support it too. So you shouldn't be trying using it on Linux deliberately either.

So I think the summary is that it's only needed for Wine. You don't need it for anything else. I remember even explicit statement on this matter in one of those kernel threads.

Case in point, without those edge cases, Wine can handle needs for faster synchronization using eventfd (esync) and etc.

[jacob]

There is a more detailed talk that goes into it. Basically, the edge cases that require that (pulse event and wait for all abstractions) are not something you should be using even on Windows. They are some quirks that exist only due to backwards compatibility needs there and Wine has to support it too. So you shouldn't be trying using it on Linux deliberately either.

So I think the summary is that it's only needed for Wine. You don't need it for anything else. I remember even explicit statement on this matter in one of those kernel threads.

Case in point, without those edge cases, Wine can handle needs for faster synchronization using eventfd (esync) and etc.

OK thanks for the explanation. My initial understanding was that NTSYNC somehow offers better performance.

[shmerl]

OK thanks for the explanation. My initial understanding was that NTSYNC somehow offers better performance.

May be it's somewhat better implementation, but not really better performance by much over esync or fsync from benchmarks.

[EphemeralEft]

I really hope Elizabeth Figura gets better at making patches and sending them.

I understand the process is cumbersome and archaic, no having something like GitLab or better is a mess. UT this is a very desired feature and extra efforts such as an additional developer would be very good. I hope CodeWeavers consider it!

Have you ever submitted patches to the upstream kernel?

[dlq84]

OK thanks for the explanation. My initial understanding was that NTSYNC somehow offers better performance.

Better performance compared to an emulated ntsync.

[F.Ultra]

Better performance compared to an emulated ntsync.

in userspace using ipc for every lock and unlock of the mutextes between wine and wineserver. It's not faster than the emulated ntsync with esync/fsync.

[V1tol]

Issues with other sync mechanisms are well known. This thread https://github.com/ValveSoftware/Proton/issues/4568 and many others game specific, like this search for example https://github.com/search?q=repo%3AV...nc&type=issues

[marlock]

So fsync and fsync2 are probably better for linux native usecases, but for proprietary windows games wine needed something that better matches (aka perfectly) the windows equivalent, not something "great but slightly too different" like both fsync versions turned out to be... and it's mostly proprietary software so we can't get in there and make however-many windows games that (ab)use the windows API use the native linux stuff in a more efficient manner

it obviously sucks that it took 3 kernel APIs to get it "right" for this usecase, but this is obviously a "hard problem" not someone being incompetent, and the 2 previous APIs are great for native linux use (this was even one of the reasons why people were motivated to pursue the first fsync, there was a lot to gain), so we just had a longer wait period for what we were aiming at in the gaming realm...

..and nobody died! yay!