 So, my name is François Tijot and I'm reachable on IRC over email. I generally hang out on FreeNode. I'm an independent consultant and system engineer. I'm an X11 and a BSD user since many years now. I've been a Dragonfly developer since 2011. I originally ported the i9-15 and a Radeon driver to Dragonfly. I have been updating the i9-15 drivers than them. Dragonfly is a UNIX-like operating system. It's a BSD descendant. It was originally forked from FreeBSD in 2003 by someone called Mathieu Dylan, who is sort of genius in his own way. Dragonfly is high-performance and scalable. It uses per-core replicated resources and many operations are naturally lockless. So it really likes high-core code, SMP systems and so on. Dragonfly uses an innovative HammerFile system. A newer version will be coming this year. It's really great for disaster recovery or heavy storage in general. The HammerFile system can return history. All transactions can be kept on disks for up to 60 days. History can be streamed between local and remote file systems. It can be used in a sort of real-time way. So it's really great for disaster recovery and general heavy storage systems. There's also integrated data application, cheap data application. You don't need tons of memory to duplicate data. It's great with small servers like machines having only 4 gigabytes or so. And I have been successfully using it on some client systems, using DNA or proteins or generally scientific data. And now I will focus on the graphics drivers. So all graphic drivers these days are based on Linux. There are many, many people, corporate developers, developing, writing graphic drivers for Intel in particular, but also AMD and so on. Nobody is working on Dragonfly. All of them work in Linux. I guess nobody has heard of Dragonfly in that area. So I have to manage with the current situation and port the Linux drivers to Dragonfly. The easiest way I have found to do that is actually not to port the drivers, but to reimplement a Linux subsystem in the Dragonfly kernel. Most modern graphics in Linux use something called the DRM subsystem, which means Direct Rendering Manager. This subsystem and the drivers themselves directly use tons of Linux APIs. And I had to reimplement these APIs and, in general, make the drivers believe they were running in a Linux kernel. So for the purpose the Dragonfly kernel can be considered an implementation of Linux. I was quite lucky for many BSD systems already at limited Linux API support, limited Linux API implementations. When I first started, OpenBSD was probably the most successful BSD for DRM support. There were many APIs I took, I took the implementations from OpenBSD. There was also a specific subsystem for some high-performance network devices in FreeBSD using Linux APIs. At some point, NetBSD people decided to also port the DRM subsystem and implement many things missing in Dragonfly. So I took a bit from all other BSD projects. We also had some subsystem we managed to use to reimplement other Linux APIs, like IDR, which is a sort of small integer registering subsystem. Occasionally, we also took some implementations from Linux itself. Contrary to popular beliefs, all Linux kernel code is not under a GPL license. There are many PCs under more liberal licenses like MIT, X11, and so on. And this is particularly true for DRM subsystem and drivers. Our Linux compatibility layer keeps growing from year to year. We now have more than 100 include files. They mostly are wrappers for other APIs which were already implemented as Linux APIs or BSD-specific APIs. Most of the wrappers are under a too-close BSD or MIT license. The i9-15 kernel driver is mostly in the same state as the one found in Linux 4.7.10. We support Core 2 to Kabylag GPUs, which makes it GPUs from about 2005, 2006 to the current generations of hardware. More recently, Linux version support is being worked on. Many people have helped. A general story of the i9-15 kernel driver. In 2010, there was a GSOC, a Google Summall Code project. A student called David Schau tried to work on the i9-15 support. He did many things, but for many reasons, I don't really know. His work was not integrated into the Dragonfly source code repository. So it was a bit of a waste, but at least when I tried to understand what happened years later, I found many discussions and ideas I simply could reuse without trying to waste time finding out myself what had to be done. I started to work on porting i9-15 two years later in summer 2012. At that point, FreeBSD had just released a new port of i9-15 from Linux, and it was working on current hardware. Since FreeBSD and Dragonfly were somewhat closed due to the shared history, I decided to port the drivers from FreeBSD and not directly from Linux. One year later, we had the driver working reasonably well. We had to implement some low-level support for cache management, which we didn't expect at all at first, but that really was the missing piece which allowed us to get the driver working. After that, I discovered FreeBSD had stopped updating its driver. Nobody told me exactly what was happening or what the situation was. People in the FreeBSD community apparently still believed the work in progress updates would be committed, would be pushed in the future, but nothing happened, so I didn't really understand what was going on. At some point, I decided to try porting newer changes from Linux directly. It was not until one year later that we had working as well support, as well as the newest Intel GPU generation at that time. Since then, I have been steadily upgrading our Linux driver version. We are now at the Linux 4.7.10 level. All currently sold i9-15 hardware is supported out of the box. DRAM Radeon is another driver. I started to port it one year later than the i9-15 driver. It is currently mostly synchronized with the same Linux version, Linux 4.7.10. It uses a special subsystem for memory management which is called TTM. Virtual memory management is hard. Not many people understand really what is going on at its low hardware level. It has been stuck on the Linux 3.11 level for four years now. There were also many people involved in debugging and helping to improve various subsystems related to Radeon support. The story was in the summer of 2013, I started porting the Radeon driver. It was working about one year later. At that point, we updated it from time to time to newer Linux versions. But it has been somewhat neglected. Since this year, David Chaos, the original GSOC author, decided to partially update it to Linux 4.7.10. But unfortunately, there are problems with this update and there are talks of a partial revert. The MDGPU driver is a new GPU driver for newer Radeon hardware. I don't really know what the Radeon connames mean in terms of commercial graphic connames. But it's generally required for newer GPU families. Nobody is known to be working on it and this has not changed since 2015. Nouveau support. Nouveau is the Linux kernel driver for NVIDIA hardware. NVIDIA hardware was never really well supported since NVIDIA itself, the company, loves to push its proprietary driver everywhere. Support has actually regressed since at some point there was a 2D accelerated driver in Xhork. But it has not been updated for years and cannot be used with Radeon hardware. So almost nobody in the Radeon flag community has NVIDIA hardware. I still played a bit with the driver and it poses an interesting challenge. Some file names are present with the same names in different subdirectories and our build system cannot compile them. I guess it could be fixed by renaming some of them or changing the build system a bit, but there has not been enough interest for people to do that. Well, actually there was a bit of interest for NVIDIA hardware, but in order to disable it. The only improvement we've had since 2015 on that front is it is now possible to disable NVIDIA hardware on hybrid laptops. So people can now force the use of the i9-15 driver and use their laptop out of the box with it. We also have a Visa driver. It's interesting. It's basically using small firmware inspections. There's a very old and low-level BIOS API. And it allows the use of NVIDIA hardware as a damn-frame buffer. It can also be used with some other GPUs like Intel and Radeon, but since they have accelerated drivers, it's only really useful for NVIDIA at this point. Of course, nothing is accelerated, so if you try to display static images like pictures and exterms and so on, it's fine. But if you try to play video or animations, well, everything will be dog-slow. Now, all of these drivers except Visa use the Generic DRM subsystem. It's a bit of a mixed bag. In order to be able to support current hardware and update drivers and so on, I have somewhat neglected it. So we have some parts up to Linux 4.7.10, but others much older. For example, we have no DRM master and no DM above support. Well, it's not really been problematic with applications, but at some point it will probably become to implement the missing pieces. One of the recent changes was related to the I2C subsystem. The I2C bus is a low bandwidth bus in general. It's used to provide additional information on video outputs, like, for example, HDMI cables or even the old VGA connector. Monitors can describe their preferred video resolution and other capabilities so that pieces and other pieces of equipment can auto-configure themselves to use it automatically. Of course, it isn't always perfect in working, like the HDMI cable at the start of this presentation. I'm sorry for that. Anyway, the I2C subsystem is a Linux subsystem. I re-implemented it from scratch and finally pushed the changes to the Dragonfly Canal in October 2016. It eventually replaces all the free BSD and Dragonfly-specific subsystem called IIC, which was completely different. It used completely different APIs for no good reasons. It was a bit of a hindrance when trying to upgrade the driver versions. It made it much easier for me to update the I915 driver. At some point, it would probably be a good idea to change the red end driver to use it also. It's currently only used by I915. Another big change this year has been VGS switcheroo support. VGS switcheroo is a nozzle Linux subsystem used to manage hybrid graphics. Many laptops nowadays are dual GPUs, since Intel always integrate GPU in its low-end and low-power processors. Some companies like to also provide a more powerful GPU like Nvidia, 10th Mx and so on, on some laptop models. We need the VGS switcheroo support in order to manage these two GPUs to be able to use the I915 GPU if the hardware was configured to use a discrete radion or Nvidia GPU by default. Someone called Peter Must ported it in March of this year. It allows the use of I915 on hybrid graphics laptops. Peter Must also ported a different subsystem called Apple GMX. It's really specific to some Apple laptop models, some powerbooks and powermarks. Some hybrid graphics laptops provide both GPUs with full video outputs. If you program the I915 GPU, you see something on the screen or on an external video output like a VGA port, same with the Nvidia or radion discrete GPU. But on some particular Apple models, the video outputs are not directly connected to either the screen or the plugs you can use in the case. They are connected to a different component called GMX. So we have to program that chip to be able to choose whether to use I915 hardware or Nvidia hardware for example. So since April of this year, we are now able to also force the use of I915 hardware on Apple laptops. Unfortunately, this code was directly ported from Linux and not implemented. It's the chip LV2 code, so we put it in a separate place. Just to be sure not to mix it with more liberally licensed code. I know about user and software. Dragonfly uses a system called Deports to create packages. Deports is a framework based on FreeBS Deports, which is a repository of package building instructions. And we automatically patch FreeBS Deports to improve Dragonfly support. So we have an automatic adaptation layer, and automatic tests, validation, and so on. It's single-handedly maintained by a guy called John Marino, and we now have more than 25,000 packages. And it's really a great system for Dragonfly, because it's a small community, and we don't have enough people to maintain such a number of applications. So it's great we are able to reuse FreeSD partners work and automatically create packages from this great work. We have, well, not the current version of Xorg, but the previous one. We have generally current versions of drivers. The XF86 drivers are 2D drivers. And for Intel, this is a bit special. Intel has stopped releasing newer versions, and we now have to directly use code from their Git repository. So this one is not based on FreeBS Deports, but managed locally. And K-Row is a library for generally used for 2D accelerations and displaying pictures and so on. So it's reasonably current, and Misa is a 3D driver library, and is also reasonably current version. Concretely, everything related to 2D operations and even 3D OpenGL works fine. Most graphic environments work fine. I don't think we have any GNOME users, so I don't really know about the state of GNOME, but other desktop environments like Meti or KDE are known to work well. And Paul even wrote to the Dragonfly IRC channel to congratulate us about the state of KDE support at some point. We also can play 3D games, so generally used OpenArena as a testing framework. Be sure 3D operations still continue to work fine after driver updates. It's doing great. I think that was quite fast for such an old game. Other people have also tested GPU calculation frameworks. There's something called Beignet. I don't really use it myself, but I've heard it is generally in a good state. There's also Wayland. Wayland is a bit mysterious for me. It's a sort of future Xorg version or replacement. Applications have to be ported, so I can simply use my usual window manager and tell it to use Wayland, so that's why I've not really tested it, but other people have. Apparently some versions work fine, especially with the In-N-15 driver. The challenge with newer versions is Wayland or some part of Wayland, I've heard about Western, now requires a special library called Liminput to manage mouse events, keyboard support, and so on. So people are working on it, but I'm not really involved myself. We have difficult spots, of course. One of them is virtual memory management. In general, graphic drivers now try to manage virtual memory. They have technicals deep into some kernel virtual memory systems, and it's hard to make sure that things work properly with non-linux VM subsystems, since the Dragonfly VM is very different from the Linux one. The VM models are not the same. But VM is something which is a bit out of my league, so we're lucky to have Mathieu Dillon for that. I think at this point he's the only one to really understand what's going on with such a low-level subsystem. And of course the big challenge with In-N-15 is it keeps being re-writed and re-writed. Intel people constantly make changes, much more than with other drivers. And right now I think I have more than 800 commits from one Linux version to the next, so this makes it difficult to continue updating it. We also have no problem, of course. Some recent GPUs have slight display corruptions, in some cases. There's a lot about scrambled, most pointers, and so on. Well, minor things. And it's generally only visible on most recent GPUs, so it's possible. Our In-N-15 driver is not stable enough for car-by-lake support, for example. So updating it to a new version could probably fix that. We also have a problem with some acceleration features like last-level cache support in the 2D driver. It's probably something we're not doing correctly in memory management, virtual memory management. Our key maloc functions also are known to behave differently than Linux. And one thing I didn't understand at first is Linux version of Kmaloc provides physically contiguous memory ranges. But the Dragonfly version only provides virtually contiguous memory ranges. GPU and CPU parts of the chips are not completely current. If we write something from the CPU to cache memory, it will not be completely pushed to real memory, and the GPU part of the chip will not see it. Same in the other directions. So we have to make sure cache memory is properly managed. And we should try to fix our Kmaloc function to make sure it uses physically contiguous memory ranges. So that's probably one of the reasons we have some slight display corruption in some work cases. Now about the future. Well, an obvious future thing to do will be to continue updating the N915 driver. At this point, I guess most people, most Dragonfly users have Intel hardware, Intel GPU hardware. Some rare people also use Radeon hardware, but a rough guess of my part will be more than 90% of people use Intel hardware. Most people use laptops these days, and most laptops use Intel chips. So we need to continue updating the N915 driver. Well, of course, Intel keeps creating a new driver family, new GPU families, so we have to. Otherwise, Dragonfly will not be able to work on recent GPU families and on recent laptops. Radeon drivers also need some love, but since there is such a low amount of users, it's a bit difficult to improve. It still uses all the APIs and FreeBSD or Dragonfly-specific code. There's not been a purely... a theory based on Linux. Other things to do will be to use formal test shoots and run benchmarks and so on. Try to find out more in a sort of automatic way, regressions, and fix things immediately. Another future thing to at least investigate is high-resolution timer support. Linux uses a subsystem called Escher Timer. We currently have an implementation of that subsystem in Dragonfly, which is based on the old payload mechanism, which was an original BSI mechanism, probably implemented in 1987, and it's not high-resolution at all. It's about 200 times per second. At some points, it would be interesting to re-implement high-resolution timers with a real high-resolution backend. Some developers, well, I think it was mostly Imre Vadas, began to investigate. In theory, using this facility properly would mean we could have important power savings. So right now, a modern laptop, such as the Skylake ones, uses about two or three watts per default just to de-playing XO pictures. And if we manage to drastically limit the number of times interrupt or periodic functions fire, we could tremendously decrease CPU time, decrease used CPU time, and generally improve power savings and get a much better battery life on a laptop. Now, this is about the people involved. Well, I supported the drivers. David Scho was your general JSOC student, which gave us many ideas. Many, many people were also involved and helped for various things during these last four years. So I'm done. Do you have any questions? You talked about formal test suites. Are there any, and how do they work? Well, there's a known internal test suite. The name escapes me at the moment. But at some point, some people try to use it. There's also an OpenGL test suite and an XOG one. But I've been relatively busy trying to keep up with Intel upgrades and I've not properly used them since a few years now. Have you ever tried to upstream some small changes to the Linux kernel code? Some things that you could benefit or some other BSD could benefit? Yeah, at some point, I found the hardware bug on a particular supermarket room at the board and I reported it at the bug on some channel. I think it was there next. I'm not so sure anymore. The fix was implemented by one of the Intel developers and it's now in the Linux kernel. But in general, we don't have many things to push since we're already using a relatively old version of Linux. At some points, I have found bugs in the i9-15 drivers. Driver or maybe once in the DRM system in general, but when I checked on the current Gitmaster, it was already fixed. Right now, our focus is not on trying to push changes to DRM Next or Linux. It's about being the most Linux-compatible as possible. I saw on the mailing list of previous BSD that they're also making a Linux KPI supporting DRM drivers. Do you work together with each other or are there totally separate projects? Well, it's a separate project in the sense that it's being maintained in a pre-BSD. But that KPI subsystem was originally based on more limited Linux, also Linux KPI subsystem called differently. I don't remember the name. It was used for high-performance network hardware and melanox hardware often, yeah, often. Yeah, that was the OFET stack. I originally took some of that code from the OFET stack. If you check the copyright mentions in the Linux something.h drivers, we have in Dragonfly code originating from FreeBSD and the OFET stack. In the other directions, one of the OFET developers took some of my changes and incorporated in that Linux KPI subsystem. Changes work both ways, but they cannot really be maintained in a common tree for many details as specific to Dragonfly or FreeBSD channels. Does Dragonfly implement the user pointer interface? Sorry, I didn't complete the error. Does Dragonfly implement the DRM user pointer interface? It's a DRM user pointer interface. Right, so it lets you basically malloc memory and then use NIO control to create a gem object that's backed by user malloc memory. Yeah, I see what you mean. Yeah, there are some IOCTL which shows the use of user generated data without having to copy it and change it in one way or another. I think this IOCTL is disabled at the moment. Well, implementing it requires some work and well, I prefer to keep upgrading Ion 15 driver versions than trying to take that. It could be helpful to improve performance, but at some right now what we need is to continue updating the driver and make sure we still work with the NIO verntel hardware. So it will probably be changed at some point, but this is not the highest priority right now. So in MISA and so on there is a lot of work where they are using file descriptor passing instead of shared memory directly. I forgot the name of the code that has been used for that. If you've done some work also to support these file descriptor passing APIs rather than the old shared memory interfaces. Well, not really. I have not been deeply involved with META since a long time. One of the recent MISA changes was a bit problematic but it was I think one year ago. Maybe this is a performance optimization but I have not it's a security issue. Well no, I have not really followed the Z change. I am mostly focusing on the i9-15 drivers these days. In general, we take MESA packages, the META port and the FreeBSD port street and we don't really change it. At some point we will probably need to add support to the new kernel interfaces but right now nobody has really thought about it.