7 ms·

Proposed Windows NT sync driver brings big Wine/Proton performance improvements

207 points by neogodless 3y ago

shmerl 3y ago
It's roughly comparable to existing esync and fsync solutions in performance, but the main benefit would be that Wine could finally upstream all this and there won't be a need to drag around out of tree patches.
- the8472 3y ago
  AIUI fsync is built on futex_waitv which has been upstreamed. So this has to be more than that. Edit: ah, it's about wine upstream, not kernel upstream. they won't take esync/fsync because those have some missing features. https://github.com/torvalds/linux/commit/a0eb2da92b715d0c97b96b09979689ea09faefe6 https://github.com/torvalds/linux/commit/a0eb2da92b715d0c97b...
  - mjevans 3y ago
    futex_waitv was only a small part of the whole FUTEX2 package. https://www.phoronix.com/news/FUTEX2-futex_waitv-v2 ... https://www.phoronix.com/search/FUTEX2 ... https://www.phoronix.com/news/Futex2-System-Call-RFC https://www.phoronix.com/news/FUTEX2-LPC-2020 https://www.phoronix.com/news/FUTEX2-2021-Still-WIP https://www.phoronix.com/news/FUTEX2-Bits-In-Locking-Core Though none of the articles so far have bothered looking up... 'NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects()' Not many great hits for NtPulseEvent() but the first result I got says "Function sets event to signaled state, releases all (or one - dependly of EVENT_TYPE) waiting threads, and resets event to non-signaled state. If they're no waiting threads, NtPulseEvent just clear event state." NtWaitForMultipleObjects() https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitformultipleobjects https://learn.microsoft.com/en-us/windows/win32/api/synchapi... After reading this, I'm still unclear about what's missing. A guess is the wakeup on timeout?
    - poizan42 3y ago
      For the public documentation for NtPulseEvent, see PulseEvent (which just calls NtPulseEvent): https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-pulseevent https://learn.microsoft.com/en-us/windows/win32/api/winbase/...
  - shmerl 3y ago
    Yeah, it's not upstreamed in Wine, you can check the linked video which explains why (same problem as with esync basically, some Windows logic like wait on all and nt pulse event doesn't work with it). The funny part is that those are almost never used anyway, so it's more of a formality on the Wine part to be always correct. But at least it's moving somewhere now possibly.
derefr 3y ago
Seems weird to upstream this support all as one shared kernel interface, modelled as only “NT emulation.” I’m surprised the kernel would be okay with this impl. It reminds me of when OpenVZ tried to upstream their big blob of container logic. The kernel maintainers forced them to part it out into individual patches so it could be reworked (and we ended up with cgroups and namespaces.) If Linux is missing certain kernel-provided sync primitives, why not just implement them all as regular Linux syscalls for every userland app to use (similar to how e.g. futexes were introduced) rather then crowding them all into some compatibility chardev with an ABI arcane enough that it would only ever be talked to by one library?
- rrdharan 3y ago
  cgroups was built by Google https://en.wikipedia.org/wiki/Cgroups https://en.wikipedia.org/wiki/Cgroups
- arka2147483647 3y ago
  I imagine the point is not to implement some species of sync primitives currently not supported by Linux, but to implement exactly what windows does, so one does not need to emulate them in userspace.
  - derefr 3y ago
    The point for the contributor is that, yes. The point that would convince the Linux kernel maintainers to actually accept the patchset, though, would likely be the introduction of generally-useful "species of sync primitives." In such a way that those primitives can be used to solve the "hard part" of WINE's virtualization of NT's versions of those primitives; but which wouldn't be constrained to guarantee an efficient zero-impedance call path between those implementations.
- the8472 3y ago
  The slides[0] (page 17) mention alternative solutions. One of them is faster userspace switching. That sounds a bit like something google has proposed before with switch_to/FUTEX_SWAP[1] [0] https://lpc.events/event/17/contributions/1517/attachments/1257/2549/lpc2023.pdf https://lpc.events/event/17/contributions/1517/attachments/1... [1] https://lwn.net/Articles/824409/ https://lwn.net/Articles/824409/
asylteltine 3y ago
Wow that’s huge. I hope this makes it way into proton. It’s getting to the point where windows is going to be mostly irrelevant for gaming, and ideally, for everything! Mac is a better experience for every single thing other than gaming (that may change soon too). My steam deck is an amazing mobile gaming device. I’m hoping one day I can actually just steamos on my gaming pc and dump my last vestigial windows install.
- thomastjeffery 3y ago
  Proton is a configuration system for wine. The only big problem left is kernel-aware anticheat. Ideally, we would just stop allowing game companies to hijack the windows kernel in the first place...
  - ronsor 3y ago
    Perhaps we can run (emulate?) the kernel drivers in user-space.
    - jsheard 3y ago
      That's known in the business as "bypassing the anti-cheat" and will get you banned the moment the anti-cheat provider notices what you're doing, even if you aren't actually cheating. If you tamper with, sandbox or subvert the AC in any way then they have to assume you're cheating since any signals they get from the AC can no longer be trusted.
      - ronsor 3y ago
        This is why Microsoft needs to stop signing anticheat drivers or otherwise require them to be sandboxed. AC providers will have to give up if platforms refuse to cooperate with them.
      - shmerl 3y ago
        If they don't trust you, you shouldn't trust them either. Their anti-cheat is essentially malware.
viraptor 3y ago
Even if not available upstream, I'd love it if SteamDeck included that patch in kernel+proton. Those are some massive gains, even for their narrow scope.
- Sakos 3y ago
  It's mouthwatering how good the improvements are. I can only hope somebody at Valve has taken notice and is hurriedly pushing it through the process.
  - johnny22 3y ago
    they're the same people in this regard. The patch author works for codeweavers and does work related to proton.
ornornor 3y ago
Speaking of that, is there a resource to figure out what GPUs work well in Linux? I loathe my workstation that is running a nvidia Quadro P620, the proprietary drivers are a joke… Looking to switch but it’s very hard to figure out the options based on a budget and Linux compatibility. Any pointers?
- Vilian 3y ago
  nvidia moment i rarely see complains about the amd gpus, intel a bit more because the drivers are newer, but not compared to the cluster f** that is the nvidia, and i tried
- deleted 3y ago
  [deleted]
- aappleby 3y ago
  I have a cheap RX 6400 and it is flawless in both Wayland and X.
  - rpcope1 3y ago
    I have one, and I sure wouldn't recommend it beyond being a simple display driver. The real killer on that card in particular is that it, so far as I can tell, does not have any (?) video encoding/decoding acceleration whatsoever, and generally the support on AMD cards is mediocre at best until you step up to very high power cards. That's actually one of the painful parts about video on Linux, is that if you've got something that needs GPU acceleration via libav, you've got three (or four) not so nice choices: nvidia, which has good hardware support but is hit or miss if it actually works outside of their proprietary nvenc, especially for libav and vaapi; AMD, which seems to lack hardware for this on low power cards, or it's poor where it exists; Intel, where the ARC cards don't work well (or at all) if you lack resizable BAR (which means you can't use anything with any age as the host). Intel's integrated graphics is probably the best choice, but still I'd really like a discrete GPU with good Linux h264, vp9 and av1 encoding and decoding support, as it doesn't seem to exist today.
    - 3y ago
nitwit005 3y ago
Wine code I've actually looked at. I was curious how they implemented some of it. I suppose a driver makes sense, but I'm curious how many recent programs actually use things like PulseEvent given the warnings Microsoft has put on it. People seem to have moved to the pthread-like APIs in recent code I've seen.
trentnelson 3y ago
I'm curious if anyone knows how the new threadpool primitives introduced in Vista fair in Wine/proton? Do games simply not use any of these APIs? (That's surprisingly, the threadpool stuff is easily one of the best pieces with no comprehensive counterpart on other platforms.)
- nitwit005 3y ago
  I'm sure people use thread pools for things like loading files off disk, but in general you have tasks with predictable loads that you can just dedicate threads to. You're rendering the game at a certain frame rate, playing audio, and at least somewhat predictable networking load.
bhaney 3y ago
Looking forward to this. Getting Msync[1] for wine on macOS has made a huge difference there. It'll be great to have a similar realm of improvement in wine on Linux as well. We're nearly at the point where I'd rather run most Windows software on any platform other than Windows. [1] https://github.com/marzent/wine-msync https://github.com/marzent/wine-msync
zoeysmithe 3y ago
From the comments the big gains are from using wineserver in userland but valve/steam/deck/proton uses fsync which is already a kernel api, so there then won't be these big gains. I'm very suspicious vale/proton/wine slept on 2-3x performance boosts. It sounds like this problem is already solved, but this implementation might be more elegant, but its the same performance out of edge cases.
Havoc 3y ago
Well given the spicy performance improvement stats they are clearly right about the bottleneck so something will need to be done

207 points by neogodless 3y ago

It's roughly comparable to existing esync and fsync solutions in performance, but the main benefit would be that Wine could finally upstream all this and there won't be a need to drag around out of tree patches.

the8472 3y ago
AIUI fsync is built on futex_waitv which has been upstreamed. So this has to be more than that. Edit: ah, it's about wine upstream, not kernel upstream. they won't take esync/fsync because those have some missing features. https://github.com/torvalds/linux/commit/a0eb2da92b715d0c97b96b09979689ea09faefe6 https://github.com/torvalds/linux/commit/a0eb2da92b715d0c97b...
- mjevans 3y ago
  futex_waitv was only a small part of the whole FUTEX2 package. https://www.phoronix.com/news/FUTEX2-futex_waitv-v2 ... https://www.phoronix.com/search/FUTEX2 ... https://www.phoronix.com/news/Futex2-System-Call-RFC https://www.phoronix.com/news/FUTEX2-LPC-2020 https://www.phoronix.com/news/FUTEX2-2021-Still-WIP https://www.phoronix.com/news/FUTEX2-Bits-In-Locking-Core Though none of the articles so far have bothered looking up... 'NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects()' Not many great hits for NtPulseEvent() but the first result I got says "Function sets event to signaled state, releases all (or one - dependly of EVENT_TYPE) waiting threads, and resets event to non-signaled state. If they're no waiting threads, NtPulseEvent just clear event state." NtWaitForMultipleObjects() https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitformultipleobjects https://learn.microsoft.com/en-us/windows/win32/api/synchapi... After reading this, I'm still unclear about what's missing. A guess is the wakeup on timeout?
  - poizan42 3y ago
    For the public documentation for NtPulseEvent, see PulseEvent (which just calls NtPulseEvent): https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-pulseevent https://learn.microsoft.com/en-us/windows/win32/api/winbase/...
- shmerl 3y ago
  Yeah, it's not upstreamed in Wine, you can check the linked video which explains why (same problem as with esync basically, some Windows logic like wait on all and nt pulse event doesn't work with it). The funny part is that those are almost never used anyway, so it's more of a formality on the Wine part to be always correct. But at least it's moving somewhere now possibly.

derefr 3y ago

Seems weird to upstream this support all as one shared kernel interface, modelled as only “NT emulation.” I’m surprised the kernel would be okay with this impl. It reminds me of when OpenVZ tried to upstream their big blob of container logic. The kernel maintainers forced them to part it out into individual patches so it could be reworked (and we ended up with cgroups and namespaces.) If Linux is missing certain kernel-provided sync primitives, why not just implement them all as regular Linux syscalls for every userland app to use (similar to how e.g. futexes were introduced) rather then crowding them all into some compatibility chardev with an ABI arcane enough that it would only ever be talked to by one library?

rrdharan 3y ago
cgroups was built by Google https://en.wikipedia.org/wiki/Cgroups https://en.wikipedia.org/wiki/Cgroups
arka2147483647 3y ago
I imagine the point is not to implement some species of sync primitives currently not supported by Linux, but to implement exactly what windows does, so one does not need to emulate them in userspace.
- derefr 3y ago
  The point for the contributor is that, yes. The point that would convince the Linux kernel maintainers to actually accept the patchset, though, would likely be the introduction of generally-useful "species of sync primitives." In such a way that those primitives can be used to solve the "hard part" of WINE's virtualization of NT's versions of those primitives; but which wouldn't be constrained to guarantee an efficient zero-impedance call path between those implementations.
the8472 3y ago
The slides[0] (page 17) mention alternative solutions. One of them is faster userspace switching. That sounds a bit like something google has proposed before with switch_to/FUTEX_SWAP[1] [0] https://lpc.events/event/17/contributions/1517/attachments/1257/2549/lpc2023.pdf https://lpc.events/event/17/contributions/1517/attachments/1... [1] https://lwn.net/Articles/824409/ https://lwn.net/Articles/824409/

asylteltine 3y ago

Wow that’s huge. I hope this makes it way into proton. It’s getting to the point where windows is going to be mostly irrelevant for gaming, and ideally, for everything! Mac is a better experience for every single thing other than gaming (that may change soon too). My steam deck is an amazing mobile gaming device. I’m hoping one day I can actually just steamos on my gaming pc and dump my last vestigial windows install.

thomastjeffery 3y ago
Proton is a configuration system for wine. The only big problem left is kernel-aware anticheat. Ideally, we would just stop allowing game companies to hijack the windows kernel in the first place...
- ronsor 3y ago
  Perhaps we can run (emulate?) the kernel drivers in user-space.
  - jsheard 3y ago
    That's known in the business as "bypassing the anti-cheat" and will get you banned the moment the anti-cheat provider notices what you're doing, even if you aren't actually cheating. If you tamper with, sandbox or subvert the AC in any way then they have to assume you're cheating since any signals they get from the AC can no longer be trusted.
    - ronsor 3y ago
      This is why Microsoft needs to stop signing anticheat drivers or otherwise require them to be sandboxed. AC providers will have to give up if platforms refuse to cooperate with them.
    - shmerl 3y ago
      If they don't trust you, you shouldn't trust them either. Their anti-cheat is essentially malware.

viraptor 3y ago

Even if not available upstream, I'd love it if SteamDeck included that patch in kernel+proton. Those are some massive gains, even for their narrow scope.

Sakos 3y ago
It's mouthwatering how good the improvements are. I can only hope somebody at Valve has taken notice and is hurriedly pushing it through the process.
- johnny22 3y ago
  they're the same people in this regard. The patch author works for codeweavers and does work related to proton.

ornornor 3y ago

Speaking of that, is there a resource to figure out what GPUs work well in Linux? I loathe my workstation that is running a nvidia Quadro P620, the proprietary drivers are a joke… Looking to switch but it’s very hard to figure out the options based on a budget and Linux compatibility. Any pointers?

Vilian 3y ago
nvidia moment i rarely see complains about the amd gpus, intel a bit more because the drivers are newer, but not compared to the cluster f** that is the nvidia, and i tried
deleted 3y ago
[deleted]
aappleby 3y ago
I have a cheap RX 6400 and it is flawless in both Wayland and X.
- rpcope1 3y ago
  I have one, and I sure wouldn't recommend it beyond being a simple display driver. The real killer on that card in particular is that it, so far as I can tell, does not have any (?) video encoding/decoding acceleration whatsoever, and generally the support on AMD cards is mediocre at best until you step up to very high power cards. That's actually one of the painful parts about video on Linux, is that if you've got something that needs GPU acceleration via libav, you've got three (or four) not so nice choices: nvidia, which has good hardware support but is hit or miss if it actually works outside of their proprietary nvenc, especially for libav and vaapi; AMD, which seems to lack hardware for this on low power cards, or it's poor where it exists; Intel, where the ARC cards don't work well (or at all) if you lack resizable BAR (which means you can't use anything with any age as the host). Intel's integrated graphics is probably the best choice, but still I'd really like a discrete GPU with good Linux h264, vp9 and av1 encoding and decoding support, as it doesn't seem to exist today.
  - 3y ago

nitwit005 3y ago

Wine code I've actually looked at. I was curious how they implemented some of it. I suppose a driver makes sense, but I'm curious how many recent programs actually use things like PulseEvent given the warnings Microsoft has put on it. People seem to have moved to the pthread-like APIs in recent code I've seen.

trentnelson 3y ago

I'm curious if anyone knows how the new threadpool primitives introduced in Vista fair in Wine/proton? Do games simply not use any of these APIs? (That's surprisingly, the threadpool stuff is easily one of the best pieces with no comprehensive counterpart on other platforms.)

nitwit005 3y ago
I'm sure people use thread pools for things like loading files off disk, but in general you have tasks with predictable loads that you can just dedicate threads to. You're rendering the game at a certain frame rate, playing audio, and at least somewhat predictable networking load.

bhaney 3y ago

Looking forward to this. Getting Msync[1] for wine on macOS has made a huge difference there. It'll be great to have a similar realm of improvement in wine on Linux as well. We're nearly at the point where I'd rather run most Windows software on any platform other than Windows. [1] https://github.com/marzent/wine-msync https://github.com/marzent/wine-msync

zoeysmithe 3y ago

From the comments the big gains are from using wineserver in userland but valve/steam/deck/proton uses fsync which is already a kernel api, so there then won't be these big gains. I'm very suspicious vale/proton/wine slept on 2-3x performance boosts. It sounds like this problem is already solved, but this implementation might be more elegant, but its the same performance out of edge cases.

Havoc 3y ago

Well given the spicy performance improvement stats they are clearly right about the bottleneck so something will need to be done