[00:00.000 --> 00:10.000]  So the next talk is by Andre on hacking the Linux kernel to get more FPS.
[00:10.000 --> 00:11.000]  Thank you.
[00:11.000 --> 00:12.000]  Can you hear me?
[00:12.000 --> 00:13.000]  Hello.
[00:13.000 --> 00:14.000]  Yes.
[00:14.000 --> 00:15.000]  Hello.
[00:15.000 --> 00:16.000]  Hi everyone.
[00:16.000 --> 00:27.000]  I'm a kernel developer from Brazil, and I work for the open source consultancy.
[00:27.000 --> 00:30.000]  Does anyone here plays on Linux?
[00:30.000 --> 00:31.000]  Okay.
[00:31.000 --> 00:32.000]  Wow.
[00:32.000 --> 00:33.000]  Cool.
[00:33.000 --> 00:35.680]  And I hope it's been great.
[00:35.680 --> 00:39.000]  And in this talk, it's not very, very technical.
[00:39.000 --> 00:44.960]  I just collected some work that has been done by a ton of people to make game on Linux better
[00:44.960 --> 00:47.040]  on the kernel side.
[00:47.040 --> 00:55.120]  So as you probably know, Linux kernel has not really a roadmap, like trying to implement
[00:55.120 --> 00:56.120]  it.
[00:56.120 --> 01:03.640]  Oh, we need 10 new file systems by the next year, or any kind of this, is all driven
[01:03.640 --> 01:05.760]  by use case.
[01:05.760 --> 01:12.400]  And I mean, if you don't have any real use case, it would be very hard to get your code
[01:12.400 --> 01:14.040]  in the kernel.
[01:14.040 --> 01:16.320]  So it's all about new use case.
[01:16.320 --> 01:20.160]  So for instance, some years ago, we had the Android that pushed a lot of new kinds of
[01:20.160 --> 01:26.720]  kernel, like DRM, and then a container that helped us grow the signals things.
[01:26.720 --> 01:32.200]  And then the cloud that mess up a little bit in the file systems stack.
[01:32.200 --> 01:41.560]  So in the past, before Proton and this kind of stuff, playing games on Linux was not that
[01:41.560 --> 01:42.560]  easy.
[01:42.560 --> 01:53.440]  We had a lot of native things, but it was really on and off and JLBC has some API, it's
[01:53.440 --> 01:59.120]  not that stable on the long term.
[01:59.120 --> 02:07.520]  And to play online, wine wasn't so stable either back then.
[02:07.520 --> 02:14.640]  So we had some native ports on the way, the source engine was one of these native ports,
[02:14.640 --> 02:20.840]  and one very interesting example of how the native version is hard to get right.
[02:20.840 --> 02:27.080]  Bioshock infinity runs very, very bad on native, but if you run the Windows version
[02:27.080 --> 02:30.760]  for Proton, it goes very great.
[02:30.760 --> 02:42.240]  So it was on and off, we had a very big financial interest on game on Linux until things changed.
[02:42.240 --> 02:49.160]  So Proton was announced a few minutes ago, it's a big project for Valve to be able to
[02:49.160 --> 02:53.120]  run Windows games on Linux as good as possible.
[02:53.120 --> 02:59.360]  So Valve has been paying a lot of community developers and consultancies like Iwale to
[02:59.360 --> 03:07.680]  enhance the Linux gaming in all the stack from wine, Mesa, and the kernel.
[03:07.680 --> 03:15.880]  And after that things started really speeding up, and now we have the Steam Deck, and we
[03:15.880 --> 03:23.040]  can see on what was all this effort about now, now we have the big picture, why they
[03:23.040 --> 03:27.600]  are pushing so hard for the Linux gaming.
[03:27.600 --> 03:34.640]  And this is from the website Boiling Steam, and this is from two years ago, it's not really
[03:34.640 --> 03:40.760]  up to date, but you can see this is like the numbers of, the red one is the reported games
[03:40.760 --> 03:49.440]  on the Proton database, and the blue one is like games that are running very nice.
[03:49.440 --> 03:56.080]  So you can see that by time we can, we are really increasing the number of games that
[03:56.080 --> 04:02.880]  we can run on Linux, and this is the Linux market share of the Steam users, and you can
[04:02.880 --> 04:11.480]  see that it's really, really small, but you can see that it's getting bigger in a, well,
[04:11.480 --> 04:15.120]  it's getting bigger all the time.
[04:15.120 --> 04:21.600]  If this line goes by infinity, you get all the market on one day.
[04:21.600 --> 04:28.320]  Okay, so now about the current features that have appeared, just because people decide
[04:28.320 --> 04:31.840]  to play game on Linux.
[04:31.840 --> 04:40.080]  The first one is a very dramatic one, I don't know why people hate that so much, but you
[04:40.080 --> 04:46.880]  can now have a case-insensitive folder on your file system Linux, and people were very
[04:46.880 --> 04:52.920]  mad about that, but yeah, it's optional, so it doesn't matter if you don't want to use
[04:52.920 --> 05:01.280]  that, and to achieve that we had, it was needed to create a unique code subsystem on the kernel,
[05:01.280 --> 05:07.480]  so now in the kernel we have all fun emojis and etc.
[05:07.480 --> 05:12.800]  And this is one of the things that I want to, that I liked about Linux kernel development
[05:12.800 --> 05:20.480]  is that this was developed for the Linux for gaming use case, but then I think the Google
[05:20.480 --> 05:29.160]  people was like, hey, this is very cool, and then they make it support for F2FS for Android,
[05:29.160 --> 05:35.320]  and yeah, so every part of the community can benefit from the effort from each other.
[05:35.320 --> 05:41.680]  So yeah, now we have case-insensitive Linux due to games, and this is, of course, because
[05:41.680 --> 05:51.160]  NTFS is a case-insensitive file system, and it's very troublesome to do that, to do the
[05:51.160 --> 05:55.360]  file path lookup from the user space.
[05:55.360 --> 06:00.840]  If you need to emulate on user space the case-insensitive thing, it's very hard to do that because you
[06:00.840 --> 06:07.200]  need to try all sorts of combinations, but on the kernel side it's very easy to do.
[06:07.200 --> 06:09.680]  You kind of abstract all the things for the user space.
[06:09.680 --> 06:18.840]  Futex, Futex is what I'm most known for, is the work that I was involved with.
[06:18.840 --> 06:26.280]  So Futex is something that is exposed from the kernel, so user space can create Mutex,
[06:26.280 --> 06:34.320]  semaphores, barriers, all kind of cool synchrony sync primitives, and on the Windows side you
[06:34.320 --> 06:42.000]  have something similar, you have the sync API from the Windows kernel, and then you have
[06:42.000 --> 06:47.440]  this function from the Windows called wait for multiple objects, that for some reason
[06:47.440 --> 06:56.200]  games really like to call that, they really rely on that, and all Linux was not that easy
[06:56.200 --> 07:06.680]  to emulate that, we tried with Eventfd, but Eventfd doesn't scale so well if you have
[07:06.680 --> 07:14.800]  so many waiters, so we moved to Futex, and then after some years I finally managed to
[07:14.800 --> 07:20.880]  get it right, and it was measured, so nowadays you can wait on multiple Futexes on Linux,
[07:20.880 --> 07:28.080]  and this is, it was created for gaming, but I know that some distributed systems and database
[07:28.080 --> 07:37.080]  also wants you to have this operation, but yeah, I still need to expose that using Petrax,
[07:37.080 --> 07:44.280]  and the Futex effort kind of created the Futex 2 project, because I was there on the main
[07:44.280 --> 07:48.720]  list, hey, hey, I need a new Futex operation, and people are like, okay, but you need to
[07:48.720 --> 07:58.040]  solve all the other Futex stuff going on, and well, I spent some time collecting why
[07:58.040 --> 08:04.800]  were people so disappointed with Futex, and now we know what we need to improve for Futex,
[08:04.800 --> 08:11.640]  and I work on the Futex 2 thing to have a lot of cool Futex operations.
[08:11.640 --> 08:17.800]  Cisco user dispatch is a feature from the Linux kernel that also was created for gaming,
[08:17.800 --> 08:24.640]  because usually when you are developing a Windows game, you want to call a syscall,
[08:24.640 --> 08:33.360]  you just use the wrapper, but some games, because of the DRM thing, they use it to call
[08:33.360 --> 08:42.440]  the syscall directly using the x86 instruction, but of course on Linux that syscall number
[08:42.440 --> 08:49.440]  didn't match the Windows one, and it was very hard for a line to deal with that, so basically
[08:49.440 --> 09:00.760]  nowadays you can select a member region and say that every time you have a syscall there,
[09:00.760 --> 09:08.120]  it will not go directly to the syscall path, it will call another program to another backend
[09:08.120 --> 09:15.320]  to deal, to see if it really should be issued that syscall number.
[09:15.320 --> 09:22.080]  So yeah, it calls a syscall, but get back to user space, I think, like that.
[09:22.080 --> 09:31.400]  GPU driver, so on DRM we are working hard to make AMD GPU better, so in the past months
[09:31.400 --> 09:39.120]  we have been, after the SNCC release, the AMD GPU was exposed to all sorts of gamers
[09:39.120 --> 09:45.960]  and music cases, and this has been popping a lot of bug reports, and we are trying to
[09:45.960 --> 09:52.960]  fix them, and also as I said, this is like kind of pushing the limits of the driver
[09:52.960 --> 09:59.600]  and the hardware, we are working on new DRM features like a sync page flip in the atomic
[09:59.600 --> 10:07.240]  API, and also working to have a better GPU reset rendering, because nowadays if your AMD
[10:07.240 --> 10:15.600]  GPU resets is kind of, you need to press the button because it won't work again.
[10:15.600 --> 10:25.560]  Also we are trying to get HDR on Linux, and also support 3D LUT on DRM.
[10:25.560 --> 10:36.400]  Also in this kind of error rendering area, we are trying to have a nice feedback for
[10:36.400 --> 10:43.520]  the user when the kernel crashes, kind of Windows blue screen with a link to, you know,
[10:43.520 --> 10:45.960]  to figure out what is going on.
[10:45.960 --> 10:52.560]  Also we have enabled P store and KDAB on Syndec, so you can have the last DMED in a safe place
[10:52.560 --> 11:00.480]  to check out what went wrong, and if everything goes right, you can submit that for, I don't
[11:00.480 --> 11:06.480]  know, for the sync servers, so they can have a look and help you to figure out what is
[11:06.480 --> 11:09.480]  going on.
[11:09.480 --> 11:19.680]  Hard to enable a lot of drivers for the Syndec, and some work on the joysticks to have a pattern
[11:19.680 --> 11:26.760]  on how joysticks exposes features to user space.
[11:26.760 --> 11:33.000]  And well, that is a lot of things, smaller things, smaller projects, like the split block
[11:33.000 --> 11:39.880]  detector handling, so basically on x86 you have this feature for, that is the split block
[11:39.880 --> 11:48.400]  that you can do atomic operations on a line of memory, but it seems that you shouldn't
[11:48.400 --> 11:55.240]  do that, and then if you do that nowadays, the kernel will penalize you and make your
[11:55.240 --> 12:03.240]  code run very slow, and of course games were doing that, so we kind of needed you, we kind
[12:03.240 --> 12:08.400]  of added a button on the kernel so you can turn off, so you can play your games.
[12:08.400 --> 12:15.360]  HDI had bottleneck, I mean it was okay, but given that a lot of people start using VR,
[12:15.360 --> 12:22.240]  NVR has a lot of HDI devices, we kind of discovered that it had a bottleneck and then
[12:22.240 --> 12:31.720]  we fixed that, and also some semantics on Unix sockets, on timestamps, on the time counter,
[12:31.720 --> 12:40.320]  because Windows and Linux, they play very different on the time keeping thing, and yeah, a lot
[12:40.320 --> 12:48.880]  of documentation that we are trying to improve along the Linux kernel, out of three, this
[12:48.880 --> 12:56.320]  is very interesting because a lot of people do on the free time, they try to hack the
[12:56.320 --> 13:05.440]  Linux kernel to play faster games, and some people develop the task schedulers, because
[13:05.440 --> 13:12.520]  on Linux, as you may know, we have the CFS, but people have cool ideas of how to task
[13:12.520 --> 13:19.680]  scheduler could be better for desktop use case to reduce the latency, et cetera, and
[13:19.680 --> 13:25.600]  these people, some of the projects are not very committed to make this upstream, so yeah,
[13:25.600 --> 13:36.800]  they use the creativity and try a lot of different ideas, and another interesting thing is that
[13:36.800 --> 13:42.240]  there are some projects out there, like Xen kernel, Shenmue kernel, Lycoris kernel, that
[13:42.240 --> 13:48.640]  are basically a bunch of unofficial kernel releases made by the community to have a better
[13:48.640 --> 13:58.160]  Linux game in kernel, and it's very fun because they grab a lot of out of patches, they grab
[13:58.160 --> 14:05.240]  working on progress patches, and make it together, and we release, it's a very experimental kernel,
[14:05.240 --> 14:11.480]  of course, it has some bugs, it has some problems, but I think it's cool to try out to see if
[14:11.480 --> 14:17.800]  your games run better on those kernels, and yeah, we are trying to, well, I always check
[14:17.800 --> 14:24.800]  those kernels to see what they come with, to see if there are cool ideas going on there,
[14:24.800 --> 14:33.280]  and for the future, I think we are going to try to enhance the program management, so
[14:33.280 --> 14:41.680]  the handheld devices can have better battery, better life, and there are so many layers
[14:41.680 --> 14:47.920]  of GPU abstraction nowadays, we follow the translation, and I think we are trained, we
[14:47.920 --> 14:54.560]  will, sometimes, eventually, the botanical will be on DRM, and we will need to support
[14:54.560 --> 15:02.200]  that huge stack better, and here, at the end, I have some lists of the patches that I said,
[15:02.200 --> 15:06.960]  so you can have a look, and I think that's it, thank you very much.
[15:06.960 --> 15:27.400]  Thank you, time for questions, please raise your hand.
[15:27.400 --> 15:34.640]  No question, I have a question, like for the task scheduler, did you look into the upstream
[15:34.640 --> 15:41.320]  development that is going on right now, where you can specify schedulers through eBPF, for
[15:41.320 --> 15:42.320]  example?
[15:42.320 --> 15:49.960]  Oh yeah, I have heard about that, but I don't know if people try to replicate those schedulers
[15:49.960 --> 15:52.640]  using eBPF, but yeah, we will have a look at that.
[15:52.640 --> 16:02.440]  It might be interesting, yeah, cool, thanks a lot, oh, sorry, sorry, sorry, one question.
[16:02.440 --> 16:10.160]  Thank you, I had a question about how hard is it to introduce new stuff into the kernel
[16:10.160 --> 16:18.000]  that only you need, like you told us, like, some things were just used by you for gaming,
[16:18.000 --> 16:24.800]  so it's pretty new, you just have to use it, how hard is it, is it easy?
[16:24.800 --> 16:34.880]  It depends on, if you really, if you mess with a bunch of code, if you decrease the performance
[16:34.880 --> 16:41.560]  of something like on the server side, people will not be so happy about that, but if you
[16:41.560 --> 16:49.800]  don't mess with things that already exist, people will be okay with that.
[16:49.800 --> 16:56.800]  Thank you.