You can sign up to get a daily email of our articles, see the Mailing List page.
We do often include affiliate links to earn us some pennies. See more here.

Linux Kernel patch sent in for comments to help gaming

By - | Views: 28,334

Collabora have sent in a fresh patch for discussion to the Linux Kernel list to help Linux gaming, acting as a follow-up to their previous attempt.

The idea with their patches, which is in collab with Valve, seems primarily focused on Wine and so Proton for Steam Play due to the differences in how Windows handles things to Linux that Wine needs to support for getting good performance. As the original patch explained:

The use case lies in the Wine implementation of the Windows NT interface WaitMultipleObjects. This Windows API function allows a thread to sleep waiting on the first of a set of event sources (mutexes, timers, signal, console input, etc) to signal.  Considering this is a primitive synchronization operation for Windows applications, being able to quickly signal events on the producer side, and quickly go to sleep on the consumer side is essential for good performance of those running over Wine.

They went onto explain that current Linux Kernel interfaces fell short on performance. With their code being used, they saw a reduction in the CPU utilization in multiple titles running with the Steam Play Proton compatibility layer when compared with current methods. Additionally it doesn't rely on file descriptors so it will also solve issues with running out of resources there too.

The new patch in discussion goes about it a different way to before. Instead of extending the current interface in the Linux Kernel, they're going with building a new system call 'futex2'. It's early on as they're still building it up with this adding the new interface, that they can then expand upon.

In short: it would make Linux gaming better with Wine / Proton in future Linux Kernel versions. However, it would likely have other uses too. You can see the patch set here which is currently under discussion.

Article taken from GamingOnLinux.com.
25 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
14 comments
Page: 1/2»
  Go to:

Eike Jun 13, 2020
View PC info
  • Supporter Plus
Does that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?
eldaking Jun 13, 2020
Quoting: EikeDoes that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?

My first thought, with no specific knowledge of the details, is that you would use a single event for all the possible sources and pass a parameter to indicate which. For system events, or a non-controlled application, probably set up multiple threads that wait each for a different event and then wakes up the thread you actually want.

But this is, of course, assuming that you are just adapting an existing code. When developing for Linux directly, people would just use a different algorithm that didn't rely on that; I don't think this is a particularly fundamental feature for multi-threaded development.
x_wing Jun 13, 2020
Quoting: EikeDoes that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?

$ man poll
$ man select

That's your answer.

I don't know what is the issue with wine, but I guess that their problem may be related to fd (but is mentioned as secondary improvement, so I'm not sure...)
ShabbyX Jun 13, 2020
Quoting: x_wing
Quoting: EikeDoes that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?

$ man poll
$ man select

That's your answer.

I don't know what is the issue with wine, but I guess that their problem may be related to fd (but is mentioned as secondary improvement, so I'm not sure...)

And more recently, epoll. I don't know what their problem with fds are, but everything being an fd is the best thing to have happened to unix. Things that weren't an fd turned out to be the most problematic (pid, signals), and they are turning into fds in recent Linuxes too.

Maybe they can get windows-y programs to run faster with windows-y kernel features, but I certainly hope no one would use this feature outside wine.
Eike Jun 13, 2020
View PC info
  • Supporter Plus
Quoting: ShabbyX
Quoting: x_wing$ man poll
$ man select
```
That's your answer.

I don't know what is the issue with wine, but I guess that their problem may be related to fd (but is mentioned as secondary improvement, so I'm not sure...)

And more recently, epoll. I don't know what their problem with fds are, but everything being an fd is the best thing to have happened to unix. Things that weren't an fd turned out to be the most problematic (pid, signals), and they are turning into fds in recent Linuxes too.

Maybe they can get windows-y programs to run faster with windows-y kernel features, but I certainly hope no one would use this feature outside wine.

I guess that somewhat answers the question I would have asked:
Poll and select seem to be all about files, while...

QuoteThe WaitForMultipleObjects function can specify handles of any of the following object types in the lpHandles array:

Change notification
Console input
Event
Memory resource notification
Mutex
Process
Semaphore
Thread
Waitable timer

This still sounds useful to me.
toojays Jun 14, 2020
Quoting: ShabbyXAnd more recently, epoll. I don't know what their problem with fds are, but everything being an fd is the best thing to have happened to unix. Things that weren't an fd turned out to be the most problematic (pid, signals), and they are turning into fds in recent Linuxes too.

Maybe they can get windows-y programs to run faster with windows-y kernel features, but I certainly hope no one would use this feature outside wine.
There is no way to use fds for synchronization without a syscall. That's no good for performance-critical paths. Pthreads primitives like mutex, condition, semaphore are designed to avoid syscalls where possible. Ideally (e.g. uncontended mutex lock) they use only atomic operations, but they call futex when they need to block, or to wake other threads.

Being able to wait on multiple futexes at once seems generally useful to me.
spayder26 Jun 14, 2020
Linux supports waiting multiple objects, but only if they're backed by file descriptors, the problem with sincronization primitives is they frequently aren't, as a developer specialized on parallelism and distributed processing getting something like this mainlined would make me quite happy.
Code Artisan Jun 14, 2020
When i wanted to implement my own threading API on linux a few years ago, i found out that there were no system procedure to pause or resume a thread from another thread unlike Windows. You had to use signals for that and it was really messy.
F.Ultra Jun 14, 2020
View PC info
  • Supporter
Quoting: Code ArtisanWhen i wanted to implement my own threading API on linux a few years ago, i found out that there were no system procedure to pause or resume a thread from another thread unlike Windows. You had to use signals for that and it was really messy.

Suspending threads comes with so many caveats that on platforms there they do exits (i.e Windows) they are marked as not to be used by anything other than debuggers really, and you are instead referred to use the same kinds of thread to thread syncronization that you have on i.e Linux such as e.g condition variables.
F.Ultra Jun 14, 2020
View PC info
  • Supporter
Quoting: Eike
Quoting: ShabbyX
Quoting: x_wing$ man poll
$ man select
```
That's your answer.

I don't know what is the issue with wine, but I guess that their problem may be related to fd (but is mentioned as secondary improvement, so I'm not sure...)

And more recently, epoll. I don't know what their problem with fds are, but everything being an fd is the best thing to have happened to unix. Things that weren't an fd turned out to be the most problematic (pid, signals), and they are turning into fds in recent Linuxes too.

Maybe they can get windows-y programs to run faster with windows-y kernel features, but I certainly hope no one would use this feature outside wine.

I guess that somewhat answers the question I would have asked:
Poll and select seem to be all about files, while...

QuoteThe WaitForMultipleObjects function can specify handles of any of the following object types in the lpHandles array:

Change notification
Console input
Event
Memory resource notification
Mutex
Process
Semaphore
Thread
Waitable timer

This still sounds useful to me.

And out of that list it's mostly mutexes and semaphores where Linux is lacking (most of the others on that list have an equivalent and thus can be used with epoll). And being able to wait for a mutex or a semaphore with epoll would have been a very nice addition, BSD have kqueue where you can wait for both fd:s, signals and mutex/semaphores with the same function and it existed before epoll so quite a large number of people are upset that Linux went with their own API that had less functionality (that said I do prefer the API of epoll over kqueue, just the functionality that is lacking).

In the end it just means that you as a Linux developer write your application in a different way than what you would have done on Windows or BSD so the major problem comes with things like WINE since they have to support the WIN32 interface.

edit: It also have to be said that this patch does not solve the "listen to both fd:s and other stuff with the same interface" since it just implements a way to listen to several FUTEX:es at the same time.


Last edited by F.Ultra on 14 June 2020 at 2:56 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.