 Do you hear me? Good so good afternoon everyone. My name is François Tijoux and I will be talking about working the DRM and KMS drivers to drag-and-fly BSD And maybe closing the window About myself I'm a consultant, citizen man I'm a former CCTLD system engineer. I worked for the .fr registry. I have been Xorg and Xeleven user as well as a BSD user for a very long time I introduced free BSD in the .fr registry So some .fr machines are now free BSD machines and I've become a drag-and-fly developer since 2011 Drag-and-fly is a UNIX like operating system. It's of course BSD based It was forked from free BSD a little bit more than 10 years ago now One of the goals of the project is to be scalable Drag-and-fly at many goals at the beginning among them The project leader decided to try to Scale for multiprocessor operations differently than what most of the operating system were doing So drag-and-fly use this per core replicated resources doesn't use complicated algorithms and many operations are naturally a lot less and The goal is to keep caches as hot as possible Drag-and-fly also some very innovative features which can be useful for some workloads such as database stems It has a unique file system which has database features The hammer file system is capable of doing a story retention. Every file operation you do is Retain you can go back in story with changes See snapshots and so on Hammer also does the duplication and real-time replication to Distant file systems in a master-slave way Swap cache is a second-level file cache It uses existing swap infrastructure and is optimized for SSDs A graph is better than many words and You can see here the scalability of the system This was a benchmark I ran on a dual-zone system On the orange tail on the horizontal line, you can see the number of postgres clients And on the vertical axis This is the number of transactions per second you get So I've compared Dragonfly with two competing Linux based operating systems and Dragonfly is a green curve We'll now talk about DRM KMS drivers In detail. We had the first tentative to port the new DRM drivers to Dragonfly BSD in 2010 at that point it Became more or less obvious than if we wanted to keep running graphical applications and X11 in particular We had to implement What is called a KMS KMS means canal mod system and it's a new way to manage graphics and Linux and now other Unix like your operating systems So we had a student try to port code from Linux in 2010 He used a compatibility layer But sadly He ran into trouble very early. So he stopped his work He failed the Google Summer of God project, but try to continue later on his spare time He had some code which was apparently working on his machine But I never could get it to run in mine. So This was a bit of a waste So I started again with free BSD Two years later approximately Dragonfly was based on free BSD. So we still have many common canal APIs It seemed like a good idea at the time So in the summer I started to implement some of the low-level APIs required by the canal By December I had most of the Intel driver part in It didn't work But at least it was compiled And it took many moments to get it working and working reliably We had to implement many low-level subsystems which we never had the need for previously and Particular the i9-15 driver is special for it uses shared memory Memory which is attached to the main CPU and Yet the GPU and CPUs part of the silicon are not coherent Memory pages have to be mapped in some special way to be seen by the GPU and Mapped differently on the CPU side and we also have to manage caches page by page So this is Something very low-level very Hard to to get working reliably and it uses something called the Pat P80 Which is The page attribute table a new feature on modern CPUs So we implemented Pat support in the canal, but first we determined Cache management was the only missing part to get the driver working reliably by completely disabling CPU caches So we had the system booting like it was running on a 50 megat CPU Everything was slow as hell. You could see lines being redrawn, but at least Graphical operations were perfect Text was displayed correctly Windows appeared So everything was running fine, but very slowly After having implemented Pat support I started to work on porting the Radiant driver Which is also some very common hardware seen at MD CPUs. It's the Radiant GPUs are now integrated into AMD CPUs. So it's very important to get that working By October of last year I had the TTM and ready on part of the DRM subsystem mostly put in TTM is a special memory manager used by the ready and driver Seals actually a bit more complicated that what the Intel driver uses It's a very complex subsystem and also how to get working reliably But we finally managed to do it By Jolly of this year So One of the problem we encountered later was free BSD drop the ball More specifically on the Intel driver. There were no Significant dates to the Intel driver after the initial Commits by free BSD people The latest supported at where is two-year-olds by now See as IV bridge GPUs It's also blocking for free BSD people for the canned updates their Radiant driver and generic the arm code without breaking the Intel driver so it's a mess and Things that I switched to Linux for the new Intel upstream in September of last year and My first goal my most important goal was to get as well hardware support working there were Many issues we had to take on and in particular the free BSD code was nothing at all what the Linux drivers looked like Most modern features and maybe from Linux 3.2 3.4 the code is vastly different Free BSD also decided to keep The old DRM one code completely separate from the updated code So they have two DRM repositories The old one the new one I Ran a diff between the twos and most cut was the same. So during to in free BSD is DRM in free BSD plus a few more functions It's a mess so I tried to rebase on Linux and Selected Linux 3.8 something as a target The Linux 3.8 branch is interesting for it is the first Linux branch with working non-working as well as support Most people also based their work on Linux 3.8 the free BSD radiant developer Use Linux 3.8 as basis open BSD false also targeting Linux 3.8 and That was important for me because open BSD is apparently the best As the best BSD KMS implementation so far everything is working their feature complete with Linux and So I get I figured I could follow in their past and Use Linux 3.8 as a base so I first try to remove the most messy parts and so put both DRM directories into the same one I Removed the all DRM one radiant and in the Intel drivers and replace them per by their updated version. I Also had to clean up the HGP driver HGP is still used for many operations Linux people are moving away and don't have to use the HGP driver anymore for with recent Intel GPUs But we still have to do with it for now So basically I ran diff get diff between the Linux and Dragonfly code Try to figure out which parts were important which parts were pointless noise implement the important differences piece by piece so as to try to keep things relatively simple for each commit and not to break everything at once Among the noise problems I had Was the free BSD Intel driver used different file names for example There's one low-level API to handle Output management like screen size auto detection of whatever features the display at the end of the cable has Which is called I to see In Linux and I see in free BSD and Dragonfly. Well the free BSD Intel driver decided to rename files having I to see in their names to files with I see in their names, so Pointless differences and times of thousands of call lines of difference We add functions Present in different fires we add renamed functions for not really any good reason Renaming things from I to see to I I see was not only done for file names, but also for function names It took me a long time to figure out what was going on, but once I learned I had to Move functions arounds to reduce differences with Linux. I basically reduce the differences by half Only by moving functions around so I don't know what he was thinking, but it was a mess The free BSD Intel developer also decided to completely rewrite the driver to change style Whereas Linux used if pointer statements. He used if pointer Not zero or if pointer not know statements He added for example parentheses to all return statements in Linux We had written zero in free BSD. We had written parentheses zero and parentheses There were many things like that. He also did white space Linux used for example 8 10 12 White space characters at the beginning of some lines and the free BSD author Moved everything to four white space characters For no good reason at all as the steel the style was nice. It was clearly easy to the eye, but it introduced Nenomers amount of noise We add Tens of thousands of thousands of line of code differences only caused by this style change So I had to reduce this noise before Moving to the important pass Which I did later There are some difficult spots where I wasn't able to completely Translate code from the free BSD way of doing things to the Linux way of doing things Which is the gem a virtual memory code Jam is a low-level memory manager used by the Intel driver Different mappings depending on if you are in the CPU context or the GPU context or so on to flash caches and well, it's very rarely very low level and Very dangerous if you introduce back there If you make a little mistake you can crash your machine have your machine reboot Instantly and so on There's also the I to see versus I see API which is completely different in free BSD Dragonfly and Linux so I had to do To adapt the driver and work around these differences For the rest I implemented Linux API Which is the same all ideas you first Google student code I David show try to do Which is also what the open BSD falls are doing For that I used some wrapper code which was already presented free BSD This is completely crazy free BSD people used Linux wrappers for some of the drivers in particular in filibund drivers emc netapp panacea's people Spent years to implement Linux wrappers to have Linux drivers work in free BSD almost out of the box and The free BSD Intel developer decided to not use them So I copied this file from free BSD Adapted there to them to Dragonfly I Also used missing parts which I took from open BSD since they also have Linux API wrappers and For the rest we implemented some of them in Dragonfly such as idea Which is used almost everywhere to manage small integers in Linux See there are many reasons why I decided to use Linux wrappers One of them was the work was almost already done by other people in free BSD and open BSD but Graphic drivers in general are very complex They're fast-moving targets, especially when they're in the Linux channel And it makes more sense to change the Dragonfly canals to behave like Linux it's more Easy in the long term it helps to reduce technical depth and It's really I Think it's really the best approach to try to make the Dragonfly canal behave like Linux and Not try to change the graphic drivers All the way to be of like drivers which were developed and Dragonfly in the first place That could be more technically Correct in a way, but we just don't have the manpower to do that Only for the Intel driver Intel has something like 20 different developers working on it full-time and I'm the only one doing it in Dragonfly and then only my spare time So it makes more sense to port the Dragonfly canal to the DRM driver APIs than the opposite so we have many Incluent Linux header files which are Just wrappers to existing Dragonfly BSD APIs or generic BSD APIs They're used by I-915 radium TTM and They really help to reduce the difference compared to Linux I didn't choose them everywhere still in particular I kept the locking directives completely separate so the locking directives are specific to Dragonfly and I wanted to keep things that way to make it more obvious and the canal Subsystems worked differently in free in a free BSD Dragonfly and Linux. So I wanted to Get as well support working The first step was to reduce noise So I reduced the pointless noise caused by style differences function defined different orders and then I moved to Free BSD APIs, which I replaced by Linux once So many parts are no completely identical between the Dragonfly and Linux drivers and This really helped we fixed many bugs just by using the original Linux code and not the code modified by the free BSD developer We had angles almost everywhere The drivers know much much more solid After that, I figured out I had to update Various subsystems Particular the interrupt code was completely different in Linux 3.8 than what was in free BSD Which was based on Linux 3.2 or 3.3. I'm not completely sure I Also add to update the ring buffer codes your brain buffer is a part of memory which is used to store commands for the GPU Which is then processed in a ring fashion Commands go to the end of the buffer and then they start to be processed again at the beginning of the buffer and so on The output management code was also very special by output. I mean VGA outputs all sort of plugs and cables you can use to plug this place to GPUs it's completely different in a has-well in previous GPU generations The outputs were more or less linked to a different chipset and They are no on the CPU die and they also are no completely digital There's still some special handling for VGA support, but If I'm not mistaken, it will be removed soon in some future Intel GPU generation So we add to update the mod The driver mod management and output auto detection code Which was one of the last part I got working and Then we were able to display graphics on as well But they were correct. That was kind of fun actually for you could see window frames be displayed and window contents start to appear little pieces by pieces tell bits by bits and the former small rectangles small rectangular areas and it was caused by graphic specific Table management structures The GPU part of Intel's silicon as Its own memory management units, which are completely different Then the memory management units on the CPU part. So there are different page tables We have to manage the structures like we do for generic virtual memory operation But we have to do it differently and in particular as well as different cache attributes than previous GPU generations So once I got that right We finally had working operations and pixel perfect operations as well That was done in August of this year so quite quite some So so that was the canal and I will now speak a bit about us on for the canal part is Not independent test to be used with traditional user applications and like XORG or libraries and so on So until 2013 we used something called pkgsrc, which is the package management systems Which was created by the netbsd guys It was containing very very old versions of x11 applications and libraries Particularly we had XORG server 1.6 It was too old a version to be able to handle Recent GPUs, so I Had to update it. I tried to do some work in pkgsrc, but for many reasons it didn't happen And I myself lost interest in packaging In 2013 dragonfly switched to a new system called deports It is based on 3dsd ports and automatic adaptive layer Automatic tests and validations Version wise it was much better. We had XORG server 1.12 which was enough to get The most recent CPUs GPUs at the time working And we also had all sort of admitted software to get with it Sadly we once again start to have the problem we had with pkgsrc 3dsd port versions are beginning to lag 3dsd guys took care to update KRO which is Graphic library used by many applications To handle two dimensions null surfaces that you care to update that 3dsd still has an old User land Intel driver in its port system So I had to create a local package and Used a much more recent version It improved performance and fixed many bugs with the old driver We had the small artifacts to black bars black rectangles and so on which is now fixed by the new version But I hope 3dsd will be able to update the port system and have recent libraries and applications So the current state is the Intel driver is mostly synchronized with Linux 3.8.16 Except the lower the low level of your 12 memory code cjm code there DRM ready and the DRM ready and driver is Synchronized with Linux 3.8. It doesn't have the bug fixes from Linux 3.8.13, but it's not really a problem at this point in time and the TTM Memory manager of code used by the ready and driver is based on Linux 3.9 So generic DRM part of the code is bit of a mess we still have to update it to Make it more like what is in Linux 3.8. I Already updated some parts but others are much more older and Troublesome In the future I plan to keep synchronizing the DRM code and in particular the generic DRM code with Linux 3.8 something It's required by features like DRM Prime DRM Prime is the subsystem which handles Hardware using two different GPUs and Only one set of video outputs like if you have a laptop with a Nvidia GPU and an Intel GPU You you need some special handling to be able to display graphics on the video outputs Otherwise your own get a black screen or Whatever My goal is them to start Updating DRM drivers to more recent versions once we will have something more like Linux in the in the generic DRM code And then maybe start porting new drivers and in particular We had many people ask about Nvidia support and for that we will require the new driver a Requirement for porting nouveau was also to get the TTM memory manager working reliably Which was done with ready and so now we're good to go Another problem we have is once we start running Xorg We lose console display The traditional VGA consoles with 80 by 25 Text characters don't work anymore once we start Xorg If I try to go back to the console for example, I will get a black screen or frozen display I could try it in real time, but it's probably not a good idea right now And so we could try to Reset the GPU to be more like a traditional VGA VGA GPU once we quit Xorg or Alternatively implement a graphical TTY layer, which is what the free BSD people are doing Which was also done by open BSD Net BSD already has a graphical console It is used by non-PC architectures in particular Well, there are some patches floating around but nothing serious at this point in time So I wanted also to thank some people a constant in Belossoff Was free BSD developer who ported DRM KMS in general and the Intel driver in particular to free BSD Alexander Kabeff started to port the red end driver to free BSD and The job was completed by Jean-Sébastien Pedro and on the Dragonfly side. I did most of the porting from free BSD I did the general generic DRM part as well as the Intel and red end driver and also the GTM memory manager required by red end and some critical people Man all of that work and work relatively Jonas Hoffman spent months working on bugs on the i9-15 driver It was the one with an IE was able to display pixel-perfect pictures by disabling cache on the system Madeleine added pad support to the channel and fixed critical petrol memory bugs and Joris Jovalinly and Marcus Pfeiffer who are also Dragonfly developers and fixed critical bugs and spent long long weeks trying to find bugs and fix them. We had some stupid things like The aegyp driver trying to write memory In the middle of its window and corrupt some channel subsystems and some many things like that so So I'm done. Do you have any questions? Yes? Well, I just I Just discovered BSD was doing some significant work during this conference. So I'm running an intentional moving cursor Okay That's with a radio So Interesting see that all three projects Dragonfly and BSD have decided to take the Linux code as is So Slightly different fixes to the Linux code Should be combined No Yeah, try Yeah, trying to keep the compatible years compatible and Maybe not maybe merge them but trying to see what's going on in other BSD projects and See if bugs are fixed or improvements made. Yes. It's a very good idea in general You Said all three projects are moving to Linux compatibility layer. It's not completely true Open BSD false did that net BSD false are doing it. I just discovered it this morning I'm doing it on Dragonfly, but the free BSD Intel developer Has a different approach apparently is trying to completely re-implement the Intel driver on his own and I don't see how that's workable With BSD projects don't just don't have the manpower to do that Any other question? No, don't be shy. Okay. Well, thank you