The NTSYNC Driver for WINE Saga Was: Good News!! The NTSYNC Driver For Wine/Proton Is "Broken" For Linux 6.10

[Audiojunkie]

EDIT: The original title of this thread was "Good News!! The NTSYNC Driver For Wine/Proton Is "Broken" For Linux 6.10". It has been retitled to The NTSYNC Driver for WINE Saga

This news may seem to be bad news, or even useless news to some, but I want to explain why I believe this news is fantastic and very important to everyone here who uses WINE.

First of all, we all know that WINE and yabridge is our perfect combination for getting Windows plugins to run in our native linux hosts. What some may know and others may not, there is a custom patched version of wine available called, "WINE-TKG" This version of WINE really, really, really increases the performance of WINE. Read the following excerpt from the yabridge GitHub page on improving WINE performance:

https://github.com/robbert-vdh/yabridge

The last but perhaps the most important thing you can do is to use a build of Wine compiled with Proton's fsync or FUTEX2 patches. This can improve performance significantly when using certain multithreaded plugins. If you are running Arch or Manjaro, then you can use Tk-Glitch's Wine fork for a customizable version of Wine with the fsync patches included. Make sure to follow the instructions in the readme to build a version of wine-tkg using the default profile and don't try to use the prebuilt releases as they will have fshack enabled which tends to break many plugins that use Direct3D for their rendering. You'll also want to make sure you're running Linux kernel 5.16 or newer as those include support the _fsync_futex_waitv option that's enabled by default though wine-tkg's customization.cfg. Finally, you'll have to set the WINEFSYNC environment variable to 1 to enable fsync. See the environment configuration section below for more information on where to set this environment variable so that it gets picked up when you start your DAW.

So, the short version is that WINE-TKG exists with special patches to improve WINE performance.

https://zezic.github.io/yabridge-benchmark/

So, going on with my explanation: Back in January of this year, at the Linux Plumbers Conference, a very interesting topic came up:

https://www.phoronix.com/news/Windows-NT-Sync-RFC-Linux

Following discussions from last year's Linux Plumbers Conference, a Windows NT synchronization primitive driver has been proposed for the Linux kernel. 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. In turn this would help the performance of some Windows games/applications running on Linux via Wine and in some cases would mean significantly better performance.

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

The point of all of this is that what began as a RFC proposal, is actually moving forward! The attempt was made to get things into linux kernel 6.10, but it didn't quite make it. This means that it is very possible that in the 6.11 kernel release we'll have a huge boost of performance when using WINE. The initial numbers are amazing!

https://www.phoronix.com/news/Windows-NT-Sync-RFC-Linux

But wait! You say.... "These performance improvements are designed only for GAMES! This is true. But the very cool thing about all of this, is that even though the initial purpose is to increase the performance of games, all windows apps benefit! Also, It is very possible that the need for WINE-TKG may no longer be needed after this as well! We'll get a huge performance increase and no longer have to go through extra hassles to get this increase in performance.

So, at any rate, this news that the patches are going forward (even though not ready for 6.10) is very, very good news!

---

---

---

https://www.phoronix.com/news/Linux-6.10-NTSYNC-Broken

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

Written by Michael Larabel in Linux Gaming on 15 May 2024 at 12:18 PM EDT. 20 Comments
LINUX GAMINGWhile Linux 6.10 is poised to merge the initial NTSYNC driver for a Windows NT Synchronization Primitive driver that can help with faster Windows gaming performance under Wine/Proton (Steam Play), the driver isn't complete. The initial patches have been in Greg Kroah-Hartman's char-misc-next branch for several weeks to expose the NTSYNC character device, it isn't the entire patch series. Greg has now marked the driver as "broken" for Linux 6.10.

The NTSYNC driver basics are in char-misc-next but the rest of the patch series ironing out the functionality haven't yet been queued. It's now too late for finding it for the Linux 6.10 merge window, so Greg is marking the driver as "broken" which in turn means the driver will not be compiled for common kernel builds. Greg wrote on the message for the patch:
"The ntsync code is only partially enabled in the kernel at this point in time, creating the device node and that's about it. Don't confuse systems that expect to see a working ntsync interface by teasing it with this basic structure at this point in time, so mark the code as "broken" so that it is not built and enabled just yet.

Once the rest of the code is accepted, this will be reverted so that the driver can be correctly built and used, but for now, this is the safest way forward."

That "broken" patch for NTSYNC was picked up a few minutes ago in char-misc-next ahead of the char/misc feature pull being submitted soon for the Linux 6.10 merge window.
NTSYNC driver is broken

CodeWeavers' Elizabeth Figura had commented on the patch when it was volleyed on the mailing list:
"I was even thinking of suggesting something like this myself. Sorry for taking so long to get the rest of the patches into acceptable shape..."

Here's to hoping that the NTSYNC driver code is in good shape then for the Linux 6.11 kernel later in the year for helping speed up Windows gaming on Linux with Valve's Steam Play and Wine.
20 Comments

[k410]

Any news about NTSYNC?

[Audiojunkie]

The last messages in the thread from Elizabeth Figura came on June 10, 2024 and August 12, 2024.

The post on June 10th states:

https://lkml.org/lkml/2024/6/10/889

Hi Peter,

Sorry to bother, but now that the Linux merge window is closed could I
request a review of this revision of the ntsync patch set, please (or a
review from another locking maintainer)?

I believe I've addressed all of the comments from the last review,
except those which would have changed the existing userspace API
(although since the driver isn't really functional yet, maybe this
would have been fine to do anyway?)

Thanks,
Zeb

---

And the post from August 12th says:

https://lkml.org/lkml/2024/8/12/1059

Hi,

Gentle ping on this—this series still needs another review.

If I should go ahead and make "breaking" API changes based on the last
review, please let me know.

Thanks,
Zeb

---

So it looks to me, like Elizabeth did what she needed to do and posted the fixed patches, but for some reason, the review of these patches have been held up. I don't know why. I'll keep a look out for more information.

[tavasti]

There is also audio-related fork https://github.com/nine7nine/Wine-NSPA

[khz]

Linux 6.10 To Merge NTSYNC Driver For Emulating Windows NT Synchronization Primitives - https://www.phoronix.com/news/Linux-6.10-Merging-NTSYNC

[Audiojunkie]

Linux 6.10 To Merge NTSYNC Driver For Emulating Windows NT Synchronization Primitives - https://www.phoronix.com/news/Linux-6.10-Merging-NTSYNC

Unfortunately, that is old news. It was marked as “broken”, and is not available. There was no change in 6.11 and 6.12. The developer is now on version 5 of the patches, and has been waiting for a review of said packages since before the 6.12 window closed. I keep checking the mailing list, but so far there has been no review and no more comments since August 12. If they were to get a positive review, the earliest they could be mainlined would be 6.13.

[Audiojunkie]

I have new news. Unfortunately, it's not good. I wrote to Elizabeth Figura, and she responded to me. I'll post my message and her response:

I wrote:

---

Fri, Oct 18, 2:24 PM
to zfigura

Hello Elizabeth,

I don't know if you are aware of it, but you've got several fans that are eagerly watching for progress on your open source kernel code. The last that any of us have heard about the code is from August 12, on the lkml. As far as we can see, it looks like it has been ignored by Peter. Have you heard any new news about it? We eagerly await your response!

Best regards,

Sean Ercanbrack
(Audiojunkie on the KVRAudio, LinuxMusicians, and Cockos Reaper forums)

---

And she responded today with the following:

Unfortunately I haven't heard anything back yet. I've still been trying to get
the patch set moving again, but without any success yet.

Sorry for the very late response—I was hoping I'd be able to scrounge up some
better news than that.

--Elizabeth

---

So, unfortunately, the project is still in limbo, with no progress being made. No one has reviewed the code yet.......

[Audiojunkie]

I have some new news about the NTSYNC Driver for WINE/Proton:

Today, Elizabeth Figura made another submission attempt. Since v5 was flat-out ignored for reasons unknown, Elizabeth is reintroducing the patch series. This time, it is has been versioned at v6. It goes back and reintroduces everything about the driver, and why it would be a fantastic benefit for WINE users. "No changes were made from v5 other than rebasing on top of the 6.13-rc1 char-misc-next tree. Let's all hope that v6 gets more traction than v5 got.

Link to the email thread about the v6 series can be found here:

https://lkml.org/lkml/2024/12/9/1639

[Audiojunkie]

Arnd Bergmann, a well known Linux kernel developer, has commented on the new submission:

https://lkml.org/lkml/2024/12/9/1735

---

Date Mon, 09 Dec 2024 21:24:36 +0100
From "Arnd Bergmann" <>
Subject Re: [PATCH v6 00/28] NT synchronization primitive driver
On Mon, Dec 9, 2024, at 19:58, Elizabeth Figura wrote:

== Previous versions ==

No changes were made from v5 other than rebasing on top of the 6.13-rc1
char-misc-next tree.

I would like to repeat a question from the last round of review, though. Two
changes were suggested related to API design, which I did not make because the
APIs in question were already released in upstream Linux. However, the driver is
also completely nonfunctional and hidden behind BROKEN, so would this be
acceptable anyway? The changes in question are:

If it was impossible to use the driver, there is no regression.
I feel the entire point of marking it as broken was to be able
to add that type of change.

• rename NTSYNC_IOC_SEM_POST to NTSYNC_IOC_SEM_RELEASE (matching the NT
  terminology instead of POSIX),

No objections my me on either name.

• change object creation ioctls to return the fds directly in the return value
  instead of through the args struct. I would also still appreciate a
  clarification on the advice in [1], which is why I didn't do this in the first
  place.

  [1] https://docs.kernel.org/driver-api/ioct ... eturn-code

The git log tells me that I have written that, but I don't remember
why I put that in, maybe someone else suggested it.

My feeling right now is that returning a file descriptor number
as a small positive integer from the ioctl() return code makes
sense. On the other hand, returning pointers, negative signed
integers or large (> 32bit) 'unsigned long' values can cause
a number of issues, so I would avoid all those the same way we
discourage passing those integers as a literal 'arg' into ioctl()
instead of going through a pointer.

So either way, this looks good to me. I also looked through the
series again to double-check that you avoid the usual common
problems we list in Documentation/driver-api/ioctl.rst, and
I found this is all fine.

So with or without the two changes you listed:

Acked-by: Arnd Bergmann arnd@arndb.de

Arnd

[Audiojunkie]

It looks like I got the scoop on Phoronix with my post!

Here's the Phoronix take on the situation:

posting.php?mode=reply&t=27158

I found the comments section interesting as well.

---

NTSYNC Linux Patches Revived To Help Boost Steam Play Gaming Performance
Written by Michael Larabel in Linux Gaming on 9 December 2024 at 03:15 PM EST. 28 Comments
LINUX GAMINGBack in May for the Linux 6.10 kernel the initial bits of the NTSYNC driver was upstreamed for helping to emulate the Windows NT synchronization primitives so Windows games running under Wine/Proton (such as Valve's Steam Play) can enjoy a very nice performance boost. That NTSYNC code for Linux 6.10 wasn't yet in functioning shape and now a half-year later the newest NTSYNC patch series has been sent out for review.

Elizabeth Figura of CodeWeavers today sent out the sixth iteration of the NT synchronization primitive driver patches for the Linux kernel. This is the first update to the patches since the v5 iteration in May. There isn't any functional changes to the patches but simply re-based against the upstream Linux 6.13-rc1 state.

There does remain two open questions around some alterations to the API design that the hope is can be adapted since the currently-merged initial code is hidden behind the "BROKEN" Kconfig option and so there is hope the API design for user-space can still be altered with this patch series. The desired changes are renaming an ioctl to better match NT terminology and changing the objection creation ioctls to return the file descriptors directly.

With no fundamental changes this round for the NTSYNC patches, hopefully there is consensus and this driver work can be upstreamed soon like for the Linux 6.14 kernel in early 2025... Too bad though that these patches have just effectively been sitting around for the past half-year and from the Wine side missing out on the upcoming Wine 10.0 stable release.

The performance gains of leveraging NTSYNC do continue to look very compelling and making us all the more eager to see the rest of these patches hit mainline:
NTSYNC benchmarks

See the v6 patch series for these 28 patches ironing out the NTSYNC driver functionality.

[Audiojunkie]

Things are moving forward now--finally...

https://lkml.org/lkml/2024/12/9/1828

From Elizabeth Figura <>
Subject Re: [PATCH v6 00/28] NT synchronization primitive driver
Date Mon, 09 Dec 2024 16:08:08 -0600
On Monday, 9 December 2024 14:24:36 CST Arnd Bergmann wrote:

On Mon, Dec 9, 2024, at 19:58, Elizabeth Figura wrote:

== Previous versions ==

No changes were made from v5 other than rebasing on top of the 6.13-rc1
char-misc-next tree.

I would like to repeat a question from the last round of review, though. Two
changes were suggested related to API design, which I did not make because the
APIs in question were already released in upstream Linux. However, the driver is
also completely nonfunctional and hidden behind BROKEN, so would this be
acceptable anyway? The changes in question are:

If it was impossible to use the driver, there is no regression.
I feel the entire point of marking it as broken was to be able
to add that type of change.

Makes sense. [I figured that the BROKEN was just there to prevent anyone from trying to use a half-finished driver, and the point of committing a half-finished driver was just to reduce the number of patches that needed to be resent.]

I'll make these changes and resend.

• rename NTSYNC_IOC_SEM_POST to NTSYNC_IOC_SEM_RELEASE (matching the NT
  terminology instead of POSIX),

No objections my me on either name.

• change object creation ioctls to return the fds directly in the return value
  instead of through the args struct. I would also still appreciate a
  clarification on the advice in [1], which is why I didn't do this in the first
  place.

  [1] https://docs.kernel.org/driver-api/ioct ... eturn-code

The git log tells me that I have written that, but I don't remember
why I put that in, maybe someone else suggested it.

My feeling right now is that returning a file descriptor number
as a small positive integer from the ioctl() return code makes
sense. On the other hand, returning pointers, negative signed
integers or large (> 32bit) 'unsigned long' values can cause
a number of issues, so I would avoid all those the same way we
discourage passing those integers as a literal 'arg' into ioctl()
instead of going through a pointer.

Ah, that makes sense to me, thanks.

---

So, Elizabeth is going to make some changes and then resubmit the patches again. Furthermore, Peter finally responded:

https://lkml.org/lkml/2024/12/12/585

Date Thu, 12 Dec 2024 13:01:40 +0100
From Peter Zijlstra <>
Subject Re: [PATCH v6 00/28] NT synchronization primitive driver
On Mon, Dec 09, 2024 at 12:58:36PM -0600, Elizabeth Figura wrote:

I would like to repeat a question from the last round of review, though. Two
changes were suggested related to API design, which I did not make because the
APIs in question were already released in upstream Linux. However, the driver is
also completely nonfunctional and hidden behind BROKEN, so would this be
acceptable anyway? The changes in question are:

• rename NTSYNC_IOC_SEM_POST to NTSYNC_IOC_SEM_RELEASE (matching the NT
  terminology instead of POSIX),

• change object creation ioctls to return the fds directly in the return value
  instead of through the args struct. I would also still appreciate a
  clarification on the advice in [1], which is why I didn't do this in the first
  place.

I see no problem making those changes; esp. since Arnd doesn't seem to
object to the latter.

Elizabeth Figura (28):
ntsync: Introduce NTSYNC_IOC_WAIT_ANY.
ntsync: Introduce NTSYNC_IOC_WAIT_ALL.
ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX.
ntsync: Introduce NTSYNC_IOC_MUTEX_UNLOCK.
ntsync: Introduce NTSYNC_IOC_MUTEX_KILL.
ntsync: Introduce NTSYNC_IOC_CREATE_EVENT.
ntsync: Introduce NTSYNC_IOC_EVENT_SET.
ntsync: Introduce NTSYNC_IOC_EVENT_RESET.
ntsync: Introduce NTSYNC_IOC_EVENT_PULSE.
ntsync: Introduce NTSYNC_IOC_SEM_READ.
ntsync: Introduce NTSYNC_IOC_MUTEX_READ.
ntsync: Introduce NTSYNC_IOC_EVENT_READ.
ntsync: Introduce alertable waits.

Acked-by: Peter Zijlstra (Intel) peterz@infradead.org

[Audiojunkie]

In brief summary for those who don't want to read the small print:

Things are back on track. NTSYNC will get a revision, and then it will be assessed again for inclusion into the kernel.

[Audiojunkie]

https://www.phoronix.com/news/Linux-NTSYNC-Driver-v7

NTSYNC Linux Driver Updated With API Design Improvements
Written by Michael Larabel in Linux Kernel on 14 December 2024 at 06:36 AM EST. 27 Comments
LINUX KERNELAfter some six months of silence, this past week the NTSYNC LInux kernel driver patches were revived for completing this open-source driver to better match the Windows NT synchronization primitives to help with Wine / Proton (Steam Play) Windows gaming performance on Linux. Following those "v6" patches posted a few days ago, on Friday evening a seventh iteration of the patches were volleyed to offer up some API design improvements for this NTSYNC driver.

Now that the NTSYNC driver patches are back to being revived and discussed on the Linux kernel mailing list, hopefully within the next kernel cycle or two we'll see the rest of these patches merged after the initial bits landed back in Linux 6.10

[Audiojunkie]

Here's the link to the v7 Patch series:

https://lkml.org/lkml/2024/12/13/1257

[Audiojunkie]

There have been recent updates again. The NTSYNC Driver is still at V.7, but it is being acknowledged, and has now been applied to the testing tree. Once it has received sufficient testing, if it doesn't need any changes, it will likely be mainstreamed. I'm not yet sure which kernel version will include it. My guess would be 6.15 (but this is just a guess).

---

https://lkml.org/lkml/2025/1/7/1322

Here is what has been posted by Greg kroah-Hartman on January 7, 2025:

"Given a lack of complaints, I've now applied this to my testing tree.
Thanks for sticking with it!

greg k-h"

---

https://lkml.org/lkml/2025/1/7/1537

Here is what Peter Zijlstra had to say on January 7, 2925:

"On Tue, Jan 07, 2025 at 06:06:03PM +0100, Greg Kroah-Hartman wrote:

Given a lack of complaints, I've now applied this to my testing tree.
Thanks for sticking with it!

Right, so I acked v6, which wasn't preserved. The v7 changes are minor
and seem fine (IIRc I even suggested them some very very long time ago)."

---

https://lkml.org/lkml/2025/1/7/1617

Elizabeth Figura then responded with:

"On Tuesday, 7 January 2025 13:42:41 CST Peter Zijlstra wrote:

On Tue, Jan 07, 2025 at 06:06:03PM +0100, Greg Kroah-Hartman wrote:

Given a lack of complaints, I've now applied this to my testing tree.
Thanks for sticking with it!

Right, so I acked v6, which wasn't preserved. The v7 changes are minor
and seem fine (IIRc I even suggested them some very very long time ago).

I wasn't sure it was fine to preserve the ack across changes (even if they were the ones you suggested) and decided to err on the safe side."

---

Thank you for the review!

On Tuesday, 7 January 2025 13:42:41 CST Peter Zijlstra wrote:

On Tue, Jan 07, 2025 at 06:06:03PM +0100, Greg Kroah-Hartman wrote:

Given a lack of complaints, I've now applied this to my testing tree.
Thanks for sticking with it!

Right, so I acked v6, which wasn't preserved. The v7 changes are minor
and seem fine (IIRc I even suggested them some very very long time ago).

I wasn't sure it was fine to preserve the ack across changes (even if they were the ones you suggested) and decided to err on the safe side.

Thank you for the review!

---