Going through my usual scanning of all the “-next” Git subsystem branches of new code set to be introduced for the next Linux kernel merge window, a very notable addition was just queued up… Linux 6.10 is set to merge the NTSYNC driver for emulating the Microsoft Windows NT synchronization primitives within the kernel for allowing better performance with Valve’s Steam Play (Proton) and Wine of Windows games and other apps on Linux.
Michael Larabel
The improvements to performance of games running under Proton this new driver will bring are legitimately insane. We’re looking at a game-changing addition to the Linux kernel here, and it’s no surprise, then, to see this effort being spearheaded by companies like Valve and CodeWeavers.
Great news! Can’t wait to see the real-world benchmarks.
While this is excellent news for compatibility, it is also another major divergence from the UNIX heritage.
I wonder how far behind BSD systems will beome now wrt. modern desktop technologies. They have already had a disadvantage with docker and containers (even though BSD fans will remind us “jails” have been there for a longer time), and now these minor changes will add to the “death by a thousand cuts”.
(I might of course be completely off, and they might have already implemented this, but could not find any such reference)
And some more comparison of ntsync against baselines:
https://github.com/ValveSoftware/Proton/issues/7501
(The thread discusses Fsync as an alternative baseline).
Just to be fair, macOS is still pretty much BSD, and with “Game Porting Toolkit” and similar efforts, they are also in the Wine emulation game.
sukru,
I really liked the simplicity of BSD jails and would have liked to see containers evolve more along those lines. But yeah obviously as the leader, nearly everything targets linux and the BSDs have to copy linux is they want to stay compatible.
While they can choose not to, the death by a thousand cuts is real.
I mean LXC containers are much more like jails… just ignore docker and you are set.
There is far too much churn in the docker/kubernetes/whathaveyou world.
If we are talking about kernel APIs, I would say that Linux is already pretty much its own thing. This does not substantially increase that surface at all.
I am glad that POSIX is still a thing and that apps can target POSIX for portability. However, there are lots of things that already assume Linux and increasingly the “Linux platform” ( things like Wayland, Pipewire, and Systemd ), OCI ( Docker ) containers target Linux explicitly and you need to run the Linux kernel in a VM to pretend to run them anywhere else.
FreeBSD is trying to run OCI containers natively. They already have a Linux emulation layer that tries to match the Linux API:
https://cgit.freebsd.org/src/tree/sys/compat/linux/linux_dummy.c
Again, I am not sure these calls are very onerous from the point of view of non-Linux systems. In fact, they are guaranteed to be quite stable. So they might be easier to track than some other Linux stuff.
That is false, it is possible to implement the Linux APIs without any Linux code at all…. that is how BSD implements Mesa driver wrappers they implement the APIs but there is no Linux code going on there.
cb88,
Yes, portability toolkits are everywhere. Even Microsoft’s original WSL was a custom native implementation of Linux APIs on NT’s micro kernel. (Which turned out to be slower than just emulating Linux kernel, but the point stands).
That being said, it is always extra work, and you’d be constantly playing “catch up”
This is great but, does it have any other use other than compatibility with Windows? What I mean is if it would make sense to use this in your application in some cases instead of Linux’ native primitives.
jgfenix
I think your right that linux developers could use the NT primitives instead of unix ones once this is available, but I don’t see any obvious advantage in doing so (other than portability reasons). The NT primitives and unix primitives did not lining up perfectly and it was necessary to emulate the NT primitives with an inefficient mix of unix synchronization and polling. This didn’t negatively affect native unix software designed around unix synchronization primitives.
So, after some poking around, including the comments at https://github.com/ValveSoftware/Proton/issues/7501, it looks like the big perf deltas are against vanilla WINE, without fsync. When comparing against fsync, you’re typically seeing much smaller max FPS deltas (like single-digits in many cases), but you seem to get better 99th-percentile frame-times and overall smoother gameplay in many titles.
So the long-term benefit will likely be that everything gets standardized against Ntsync once the full set of patches makes it into the kernel, with more predictable/smoother frame rates against more games in the Steam Deck and broader Linux gaming ecosystems. Of course, this will also improve performance in non-gaming applications, but it’s pretty clear that the largest potential impact will be in the gaming space.
One other possibility is that standardizing on Ntsync will allow the WINE developers to ID other bottlenecks that may have been (somewhat) camouflaged by the process-sync inefficiencies that Ntsync resolves.
I think the long term impact will go beneath just gaming. This should make it much easier to maintain single codebase between Windows and Linux for advanced server software. Perhaps also it should make it easier to maintain linux version of elaborate drivers.
Agreed. And it will make easier for people to switch to Linux if they know that their favorite games will run as good (if not better) as they did on Windows. Now only if we could convince AAA companies to not assume all Linux users are cheaters, it would be glorious.