Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • marlock
    replied
    I'm by no means an expert, but the whole "kernel mailing list" workflow feels like "We need to talk about Kevin (2011)" material to my layman's eyes

    Is there any special reason why they don't migrate other than "too much effort, not enough spare hands, can't stop other efforts"?

    like is the codebase too big? do they have some workflows which current offerings like GitLab doesn't cover? is it the discussions history in the mailing list that they don't want broken up? or something completely different?

    Leave a comment:


  • marlock
    replied
    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!
    Last edited by marlock; 07 June 2024, 03:37 PM.

    Leave a comment:


  • V1tol
    replied
    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

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by dlq84 View Post

    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.

    Leave a comment:


  • dlq84
    replied
    Originally posted by jacob View Post

    OK thanks for the explanation. My initial understanding was that NTSYNC somehow offers better performance.
    Better performance compared to an emulated ntsync.

    Leave a comment:


  • EphemeralEft
    replied
    Originally posted by timofonic View Post
    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?

    Leave a comment:


  • shmerl
    replied
    Originally posted by jacob View Post

    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.

    Leave a comment:


  • jacob
    replied
    Originally posted by shmerl View Post

    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.

    Leave a comment:


  • shmerl
    replied
    Originally posted by ssokolow View Post

    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.
    Last edited by shmerl; 15 May 2024, 07:49 PM.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by shmerl View Post

    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."‚Äč

    Leave a comment:

Working...
X