Support us on Patreon
PayPalCollabora 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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Does that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?
0 Likes
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.
0 Likes
Quoting: EikeDoes that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?
$ man poll
$ man selectThat'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...)
0 Likes
Quoting: x_wingQuoting: 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.
0 Likes
Quoting: ShabbyXQuoting: 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.
0 Likes
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.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.
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.
Being able to wait on multiple futexes at once seems generally useful to me.
3 Likes, Who?
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.
3 Likes, Who?
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.
0 Likes
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.
1 Likes, Who?
Quoting: EikeQuoting: ShabbyXQuoting: 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
2 Likes, Who?
See more from me