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

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.

And that's the part that made OpenVZ unacceptable to integrate into the kernel — the axiomatic framework being introduced by the patch series. No matter how you split and refactor and document and drip-feed in the OpenVZ patches, they'd still just be a set of patches each proposing one component of an already-externally-designed higher-level feature, that can only exist if all the patches are accepted. (See the relevance?)

My understanding of how things should go in Linux kernel development, is that when submitting a single patch to LKML, 1. the motivating user-story should first be explained, and 2. the patch that follows should then be the most idiomatic way to solve that single problem within the existing architecture the Linux kernel. This will then 3. start a discussion, where any "specialization" of the design from its normative "obvious" form may be proposed, and justifications for this argued.

When submitting a patch series, each patch must go through this process independently. If there is any common framework to the patches, it can only be because the "obvious way" (by the consensus of all participants) to solve patch 2's user-story, with patch 1 already in place in a dev branch, is to refactor the logic of patch 1 and patch 2 together.

In other words, it should be up to the core kernel maintainers — not the contributor — to propose an in-kernel architecture like "this set of operations introduced over the last few development patch series, would make a lot of sense to expose as messages passed into a single character device." And such an architecture should be proposed because it's what's best for the kernel, rather than because having it that way would make the contributor's life easier in implementing their library.

(The only exception to this being if the aim is to support direct interoperation with some existing portable software, by exposing a syscall or device or filesystem that other platforms already have, and that existing software already depends upon on these other platforms. Which doesn't apply here — NT itself doesn't have an ntsync device!)

I would expect, if this process were followed for NT's sync primitives, that:

• some of the resulting changes would introduce ioctls;

• some of the resulting changes would add flags for the io_uring or epoll syscall families;

• and some of the resulting changes — for the legacy NT sync-primitive objects specifically — would probably become their own syscalls (probably in such a way that they only exist with a certain kernel module loaded, so that the attack surface they represent can be disabled in hardened systems.)

These changes would likely all solve the problems as stated (i.e. making it possible to execute NT software that uses sync-object X, with only a userland translation library between the kernel and the software, no RPC daemon needed) ... but these changes likely wouldn't solve the problems in the most efficient way for WINE. Not if there's any other uses — in greenfield Linux software, in virtualization of other OSes, in accelerated kernel-mode hypervision, etc — for exposing such primitives.

And also, obviously, these primitives would all end up fairly different from one-another, and from what NT expects — and so WINE would still need a fairly complex translation layer to target these syscalls. Just like it does today. Just, one without inefficiant and apparently-untenable userland arbitration.

WaitForMultipleObjects and Nt(Set|Reset|Pulse)Event are used throughout Windows source code

OpenVZ (like LXC) was more of an OS level VM alternative type of container. Docker was more of a developer oriented distribution/isolation system than OpenVZ/LXC/etc which were more of a sysadmin oriented hosting system. In the very early days Docker didn't make much sense to me until I realised that.

  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

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

After reading this, I'm still unclear about what's missing. A guess is the wakeup on timeout?

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.

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.

I get graphical glitches in gnome, it crashes GPU accelerated browser tabs, my logs are full of “FAULT_PTE ACCESS_TYPE_READ” errors, it freezes the displays for 30 seconds seemingly randomly. And that’s with the latest drivers available for Linux and the latest available 6.5 kernel.

I found it mostly worked, and then broke controller input about 3-4 months ago, and then partially fixed it last month.

What controller or stick/throttle are you using?