So the next talk is by Andre on hacking the Linux kernel to get more FPS.
Thank you.
Can you hear me?
Hello.
Yes.
Hello.
Hi everyone.
I'm a kernel developer from Brazil, and I work for the open source consultancy.
Does anyone here plays on Linux?
Okay.
Wow.
Cool.
And I hope it's been great.
And in this talk, it's not very, very technical.
I just collected some work that has been done by a ton of people to make game on Linux better
on the kernel side.
So as you probably know, Linux kernel has not really a roadmap, like trying to implement
it.
Oh, we need 10 new file systems by the next year, or any kind of this, is all driven
by use case.
And I mean, if you don't have any real use case, it would be very hard to get your code
in the kernel.
So it's all about new use case.
So for instance, some years ago, we had the Android that pushed a lot of new kinds of
kernel, like DRM, and then a container that helped us grow the signals things.
And then the cloud that mess up a little bit in the file systems stack.
So in the past, before Proton and this kind of stuff, playing games on Linux was not that
easy.
We had a lot of native things, but it was really on and off and JLBC has some API, it's
not that stable on the long term.
And to play online, wine wasn't so stable either back then.
So we had some native ports on the way, the source engine was one of these native ports,
and one very interesting example of how the native version is hard to get right.
Bioshock infinity runs very, very bad on native, but if you run the Windows version
for Proton, it goes very great.
So it was on and off, we had a very big financial interest on game on Linux until things changed.
So Proton was announced a few minutes ago, it's a big project for Valve to be able to
run Windows games on Linux as good as possible.
So Valve has been paying a lot of community developers and consultancies like Iwale to
enhance the Linux gaming in all the stack from wine, Mesa, and the kernel.
And after that things started really speeding up, and now we have the Steam Deck, and we
can see on what was all this effort about now, now we have the big picture, why they
are pushing so hard for the Linux gaming.
And this is from the website Boiling Steam, and this is from two years ago, it's not really
up to date, but you can see this is like the numbers of, the red one is the reported games
on the Proton database, and the blue one is like games that are running very nice.
So you can see that by time we can, we are really increasing the number of games that
we can run on Linux, and this is the Linux market share of the Steam users, and you can
see that it's really, really small, but you can see that it's getting bigger in a, well,
it's getting bigger all the time.
If this line goes by infinity, you get all the market on one day.
Okay, so now about the current features that have appeared, just because people decide
to play game on Linux.
The first one is a very dramatic one, I don't know why people hate that so much, but you
can now have a case-insensitive folder on your file system Linux, and people were very
mad about that, but yeah, it's optional, so it doesn't matter if you don't want to use
that, and to achieve that we had, it was needed to create a unique code subsystem on the kernel,
so now in the kernel we have all fun emojis and etc.
And this is one of the things that I want to, that I liked about Linux kernel development
is that this was developed for the Linux for gaming use case, but then I think the Google
people was like, hey, this is very cool, and then they make it support for F2FS for Android,
and yeah, so every part of the community can benefit from the effort from each other.
So yeah, now we have case-insensitive Linux due to games, and this is, of course, because
NTFS is a case-insensitive file system, and it's very troublesome to do that, to do the
file path lookup from the user space.
If you need to emulate on user space the case-insensitive thing, it's very hard to do that because you
need to try all sorts of combinations, but on the kernel side it's very easy to do.
You kind of abstract all the things for the user space.
Futex, Futex is what I'm most known for, is the work that I was involved with.
So Futex is something that is exposed from the kernel, so user space can create Mutex,
semaphores, barriers, all kind of cool synchrony sync primitives, and on the Windows side you
have something similar, you have the sync API from the Windows kernel, and then you have
this function from the Windows called wait for multiple objects, that for some reason
games really like to call that, they really rely on that, and all Linux was not that easy
to emulate that, we tried with Eventfd, but Eventfd doesn't scale so well if you have
so many waiters, so we moved to Futex, and then after some years I finally managed to
get it right, and it was measured, so nowadays you can wait on multiple Futexes on Linux,
and this is, it was created for gaming, but I know that some distributed systems and database
also wants you to have this operation, but yeah, I still need to expose that using Petrax,
and the Futex effort kind of created the Futex 2 project, because I was there on the main
list, hey, hey, I need a new Futex operation, and people are like, okay, but you need to
solve all the other Futex stuff going on, and well, I spent some time collecting why
were people so disappointed with Futex, and now we know what we need to improve for Futex,
and I work on the Futex 2 thing to have a lot of cool Futex operations.
Cisco user dispatch is a feature from the Linux kernel that also was created for gaming,
because usually when you are developing a Windows game, you want to call a syscall,
you just use the wrapper, but some games, because of the DRM thing, they use it to call
the syscall directly using the x86 instruction, but of course on Linux that syscall number
didn't match the Windows one, and it was very hard for a line to deal with that, so basically
nowadays you can select a member region and say that every time you have a syscall there,
it will not go directly to the syscall path, it will call another program to another backend
to deal, to see if it really should be issued that syscall number.
So yeah, it calls a syscall, but get back to user space, I think, like that.
GPU driver, so on DRM we are working hard to make AMD GPU better, so in the past months
we have been, after the SNCC release, the AMD GPU was exposed to all sorts of gamers
and music cases, and this has been popping a lot of bug reports, and we are trying to
fix them, and also as I said, this is like kind of pushing the limits of the driver
and the hardware, we are working on new DRM features like a sync page flip in the atomic
API, and also working to have a better GPU reset rendering, because nowadays if your AMD
GPU resets is kind of, you need to press the button because it won't work again.
Also we are trying to get HDR on Linux, and also support 3D LUT on DRM.
Also in this kind of error rendering area, we are trying to have a nice feedback for
the user when the kernel crashes, kind of Windows blue screen with a link to, you know,
to figure out what is going on.
Also we have enabled P store and KDAB on Syndec, so you can have the last DMED in a safe place
to check out what went wrong, and if everything goes right, you can submit that for, I don't
know, for the sync servers, so they can have a look and help you to figure out what is
going on.
Hard to enable a lot of drivers for the Syndec, and some work on the joysticks to have a pattern
on how joysticks exposes features to user space.
And well, that is a lot of things, smaller things, smaller projects, like the split block
detector handling, so basically on x86 you have this feature for, that is the split block
that you can do atomic operations on a line of memory, but it seems that you shouldn't
do that, and then if you do that nowadays, the kernel will penalize you and make your
code run very slow, and of course games were doing that, so we kind of needed you, we kind
of added a button on the kernel so you can turn off, so you can play your games.
HDI had bottleneck, I mean it was okay, but given that a lot of people start using VR,
NVR has a lot of HDI devices, we kind of discovered that it had a bottleneck and then
we fixed that, and also some semantics on Unix sockets, on timestamps, on the time counter,
because Windows and Linux, they play very different on the time keeping thing, and yeah, a lot
of documentation that we are trying to improve along the Linux kernel, out of three, this
is very interesting because a lot of people do on the free time, they try to hack the
Linux kernel to play faster games, and some people develop the task schedulers, because
on Linux, as you may know, we have the CFS, but people have cool ideas of how to task
scheduler could be better for desktop use case to reduce the latency, et cetera, and
these people, some of the projects are not very committed to make this upstream, so yeah,
they use the creativity and try a lot of different ideas, and another interesting thing is that
there are some projects out there, like Xen kernel, Shenmue kernel, Lycoris kernel, that
are basically a bunch of unofficial kernel releases made by the community to have a better
Linux game in kernel, and it's very fun because they grab a lot of out of patches, they grab
working on progress patches, and make it together, and we release, it's a very experimental kernel,
of course, it has some bugs, it has some problems, but I think it's cool to try out to see if
your games run better on those kernels, and yeah, we are trying to, well, I always check
those kernels to see what they come with, to see if there are cool ideas going on there,
and for the future, I think we are going to try to enhance the program management, so
the handheld devices can have better battery, better life, and there are so many layers
of GPU abstraction nowadays, we follow the translation, and I think we are trained, we
will, sometimes, eventually, the botanical will be on DRM, and we will need to support
that huge stack better, and here, at the end, I have some lists of the patches that I said,
so you can have a look, and I think that's it, thank you very much.
Thank you, time for questions, please raise your hand.
No question, I have a question, like for the task scheduler, did you look into the upstream
development that is going on right now, where you can specify schedulers through eBPF, for
example?
Oh yeah, I have heard about that, but I don't know if people try to replicate those schedulers
using eBPF, but yeah, we will have a look at that.
It might be interesting, yeah, cool, thanks a lot, oh, sorry, sorry, sorry, one question.
Thank you, I had a question about how hard is it to introduce new stuff into the kernel
that only you need, like you told us, like, some things were just used by you for gaming,
so it's pretty new, you just have to use it, how hard is it, is it easy?
It depends on, if you really, if you mess with a bunch of code, if you decrease the performance
of something like on the server side, people will not be so happy about that, but if you
don't mess with things that already exist, people will be okay with that.
Thank you.