autotldr@lemmings.world
on 24 Jan 2024 13:05
nextcollapse
This is the best summary I could come up with:
This driver would expose /dev/ntsync as a new character device for implementing some of the Windows NT synchronization primitives directly within the Linux kernel.
Elizabeth Figura of CodeWeavers who published the “request for comments” (RFC) to various Linux kernel mailing lists explained of the motivations for this synchronization primitive driver for targeting Windows NT kernel behavior: "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.
The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness.
With these “NTSYNC” kernel driver patches there are benefits to different Windows games on Wine from 21% with Metro 2033 to as much as 678% with DiRT 3!
In any event as this series is marked “RFC” and there are some open design elements to its implementation, it may take some revisions before settling down on something that could be upstreamed.
The original article contains 405 words, the summary contains 166 words. Saved 59%. I’m a bot and I’m open source!
joojmachine@lemmy.ml
on 24 Jan 2024 16:18
nextcollapse
I’m all in for performance improvements, hope to see this reach Proton ASAP
Chewy7324@discuss.tchncs.de
on 24 Jan 2024 19:21
nextcollapse
The patches are from CodeWeavers, and some of their work is cooperation with Valve, so hopefully proton gets those changes quickly. It usually takes a while before proton is based on a new wine release.
demonsword@lemmy.world
on 24 Jan 2024 22:29
collapse
Windows NT Sync Driver Proposed For The Linux Kernel
demonsword@lemmy.world
on 26 Jan 2024 17:43
collapse
yes, of course, but I was just pointing out that the proposed changes are mainly in kernel space, not in wine itself
possiblylinux127@lemmy.zip
on 24 Jan 2024 18:00
nextcollapse
Honestly this is the kind of thing we needed from React os. It would of been nice to be able to run the react is kernel in the background and then have wine make calls to it.
ElectroLisa@lemmy.blahaj.zone
on 24 Jan 2024 18:46
nextcollapse
What happened during the DiRT 3 benchmark lol, this game easily goes above 200 fps
NekkoDroid@programming.dev
on 24 Jan 2024 22:25
collapse
Those benchmarks under “Upstream” does not include esync/fsync from my understanding
LaterRedditor@lemmy.world
on 25 Jan 2024 23:49
collapse
Is there any risk of lawsuits from Microsoft for all these?
Chewy7324@discuss.tchncs.de
on 26 Jan 2024 00:36
collapse
No, this kernel patch will be different to what’s in Windows code. It implements what’s necessary for wine to be more performant, not the actual Windows API itself.
Wine implements those Windows API/ABIs, which is legal because it’s done by reverse-engineering. I believe in some countries (US?) it’s also necessary for the devs to never have seen Windows code.
PS: Google v. Oracle is a US supreme court decision where Oracle lost at trying to patent Java API’s.
threaded - newest
This is the best summary I could come up with:
This driver would expose /dev/ntsync as a new character device for implementing some of the Windows NT synchronization primitives directly within the Linux kernel.
Elizabeth Figura of CodeWeavers who published the “request for comments” (RFC) to various Linux kernel mailing lists explained of the motivations for this synchronization primitive driver for targeting Windows NT kernel behavior: "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.
The NT synchronization APIs are too complex to implement on top of existing primitives without sacrificing correctness.
With these “NTSYNC” kernel driver patches there are benefits to different Windows games on Wine from 21% with Metro 2033 to as much as 678% with DiRT 3!
In any event as this series is marked “RFC” and there are some open design elements to its implementation, it may take some revisions before settling down on something that could be upstreamed.
The original article contains 405 words, the summary contains 166 words. Saved 59%. I’m a bot and I’m open source!
I’m all in for performance improvements, hope to see this reach Proton ASAP
The patches are from CodeWeavers, and some of their work is cooperation with Valve, so hopefully proton gets those changes quickly. It usually takes a while before proton is based on a new wine release.
Proton would still need to make use of it.
yes, of course, but I was just pointing out that the proposed changes are mainly in kernel space, not in wine itself
Honestly this is the kind of thing we needed from React os. It would of been nice to be able to run the react is kernel in the background and then have wine make calls to it.
is this what used to be called winesync?
What happened during the DiRT 3 benchmark lol, this game easily goes above 200 fps
Those benchmarks under “Upstream” does not include esync/fsync from my understanding
Is there any risk of lawsuits from Microsoft for all these?
No, this kernel patch will be different to what’s in Windows code. It implements what’s necessary for wine to be more performant, not the actual Windows API itself.
Wine implements those Windows API/ABIs, which is legal because it’s done by reverse-engineering. I believe in some countries (US?) it’s also necessary for the devs to never have seen Windows code.
PS: Google v. Oracle is a US supreme court decision where Oracle lost at trying to patent Java API’s.
…wikipedia.org/…/Google_LLC_v._Oracle_America,_In….