 So, yeah, as I said, I'm a Red Hat employee, I work on Xorg and kernel graphics for our enterprise Linux product and when we have time for everything else we do, pretty much is most of the time, thankfully. My talk is anatomy of modern Linux graphics driver. As usual, I submitted the talk title and then had to figure out what the hell I was going to talk about. So hopefully it's close enough. Just to start off, no animals are harmed in the making of these graphics drivers. But a lot of developers have been tortured, unfortunately. So one of the questions we get is, you know, the Xorg graphics stack, you know, Linux, it's quite confusing, you know, there's a lot of pieces to it and a lot of things. This is sort of like the Xorg architecture diagram. This picture is one, I'm going to show you a PDF found on an Ubuntu forum called the Xorg architecture diagram. If you've got, you know, if you've got your Google there, you'll be able to see it because it doesn't show very well up here. I have to kill this other thing first, don't I? Oh yeah, I'll zoom out for it. So basically some guy on the forums, I don't know how he did this, but he seemed to have got every word that he could find that was associated with Xorg graphics or Linux or, and put them all into a very weird graph. Got some strange highlights in weird places like, let's see if I can even figure out the zoom back in again. So poor, poor, all evinces suffering. But you can get names over here, you can just see the edge of Keith Packard's name. And then you can see the key creation, K drive, and then you've got only a couple of human names appear. And it's very, it's a very unusual diagram. But if you search for Xorg, X dot org architecture diagram in Google, you'll pick this PDF up. And the problem was quite a lot of it is actually semi-accurate. But you could see why people get confused. And drawing diagrams like that doesn't really help clean up the confusion much. That was not what I wanted. So today I'm just going to try and, in the first part of my talk, I've sort of got two parts. The first part is sort of trying to clean up the pieces that are in the current system. Because we've been migrating from our old X design to a new kernel-based Linux system, Keith's talk went into it a bit yesterday. And I'll just do it slightly. So first off, the top of the stack, the brains, it's the users, the applications, they're the things that make the decisions, what you want to do. Users want your computer to do stuff. So they put the information in there. They're the controller, really. So my anatomy analogy broke down pretty quickly then, because I couldn't think of anything decent. So the top level, first thing that applications and users generally are interacting with, in a lot of cases, especially now we're trying to 3D and stuff like that a lot more, is Mesa drivers. So what's in the Mesa system at the moment? The main chunk is, it's probably two or three main, but it's basically an OpenGL to hardware conversion layer. The quite large chunk of it now is a shader compiler. Before, we didn't really have something like that. But OpenGL has sort of evolved from a fixed function system to a highly programmable shader-based system. And we didn't quite keep up with that for a long time with Mesa. Mesa was very designed around the whole fixed function pipes and older drivers. And it was quite simple to bring up a driver. But when shaders started coming along, we sort of got left behind quite quickly. Because we didn't have a shader compiler. We had a slightly optimizing assembler to do real GLSL and real programs and real applications. So one of the biggest projects that's gone into the modern Mesa framework is the GLSL compiler from the team at Intel. And that's made quite a large difference to what we can support in terms of GL features and hardware features. Because all the hardware has been programmable since maybe eight years ago, seven years ago. So it's catching up. And it was a long way to catch up. Yeah, it's programmable, partly, if you use the CPU for the other half. So Keith was just asking to account i9-15. But that's probably where we start the programmable logic of things. So the driver interface as well. A lot of parts of Mesa were still modeled around that whole ancient fixed function thing. Your driver had to have an awful lot of parts of GL knowledge. So we sort of split Mesa has sort of gone into two camps. There's the classic driver model and the gallium driver model. Classic driver model is currently only being used by the Intel driver. And anyone that has hardware that's a pre-shader really. There's some random hardware that people are actually using. The advantages of classic, I'm not 100% aware of, but if you've already got a driver that was working, doing another driver from scratch is quite a lot of effort. And getting it back to the same level again is quite a lot of effort. So if you have a working driver, which Intel were probably the only people in that position, it doesn't make as much sense to go and use the gallium system. The classic driver, though, has a lot of stuff that every driver has to do. And you end up repeating the same mistake. So you run a set of tests on a new driver, and you'll end up just copying the code over from the other driver. And it's like the amount of code that could have been shared versus the amount of code that actually was shared, it just got very, especially when they started implementing things like frame buffer objects. Every driver has to understand frame buffer objects. But there's not a huge, there's some common code. But then there's a lot of things like in open GL frame buffer objects are rendered upside down versus what normal GL does. And every driver has all these special cases to deal with that. And it's like the abstraction isn't there. What gallium did was it decided to remove the GL stuff from the driver, that it would hide as much of the GL complexity away from the driver and would define a neutral interface between the two. So pretty much the interface between a gallium driver and Mesa, and pretty much anything else, it's like a shader language. So it's an intermediate representation of shaders and a bunch of state objects that you can pass. The idea being as well that you can have this one gallium driver, and then you can change from a GL interface to an XORG driver to an OpenVG, Interior, OpenCL. But you can build all of these things completely separate and then plug in the drivers into the model. And you don't have to rewrite large, huge chunks of code to add a new interface to it. So far, really, the OpenGL is probably all it's gotten up to speed. The OpenVG one, I think, sort of is mostly working. Someone has done a DX10 interface. So something that, say, Wine could use. But the Wine guys aren't really interested. But this guy just didn't approve that it could be done. So you end up with a DX-like interface, because it requires all of the Windows framework around it to do a real DX interface. Interior also with gallium drivers, you could plug them into Windows. But it's a bit harder. People think that people go, well, you just take the treaty driver and you could put it in Windows. But there's a lot of things like you need the 2D set up, and you need to have matching screen set up and stuff. So it's a lot messier than people. If you're designing a whole Windows driver from scratch, it makes sense. If you're not, it's way too much work. So yeah, the classic versus gallium debate, I'd say will continue. Certain things that gallium offers still, for cards that don't have vertex shaders, it has LLVM integrated, so you get faster vertex shaders on your CPU, which is something we'd wanted for a long time. So yeah, I think in terms of hardware that gallium supports really well, we've got R300, R500 driver. It's shipping by default in nearly all distros. R600 supports everything up to the latest AMD graphics chip, so like Nord Nylons that they've just released. I think the only one that they don't support is the top range of the very newest one. And they're working on that at the moment. Somebody decided to change the whole chip architecture in a minor version. And we have to rewrite the whole compiler. It's like, no, thanks for telling us. So there's also the Nouveau reverse engineer drivers, pretty much covering everything, I think, from the NV30, NV40, NV50, and the new Fermi chips have a 3D driver. And I don't think there's anyone at the other ones. And there is community Intel gallium drivers, but they're not currently really usable. They're just sort of like the stuff that's developed for people to play around with gallium on that hardware. And then there is VMware's driver, which they use to do the virtual graphics stuff. Classic drivers, as I said, there's pretty much just Intel as our favorite holdout. We may change. Right, yeah. Well, that's fine, but I just hate the fact that I have to know about GL in my driver. Once I did FBOs once in a Classic Driver, doing FBOs again in the Classic Driver had no interest. So that's pretty much what Mesa is going on to now. And the modern Mesa will be GLSL. We're pushing forward on the slide later on where we're trying to get GL up to modern standards. Currently, GL 2.1 is pretty much as high as we can get to, considering GL is now at 4.1. You can see there's a bit of work to get done. So what are components do we have? I've got a slide here demonstrating what the old XORG drivers used to look like. Very large, full of things that probably shouldn't have been there. Big dinosaur type things. Well, that was Godzilla. The fact that you can find Godzilla's anatomy on the internet is proof enough that the internet is useful. Yeah, basically, so before we did the re-architecture of everything, and again, Keith, the XORG drivers contained all the mode setting code, all the rendering, acceleration. And I think you said Keith, well, that's 60 or 70% of the Intel driver was mode setting code. And basically, with the changes in modern graphics hardware, so the move towards things like even DVI had hot plug support, display port has insane training requirements that need. So you plug a display port monitor in. They have to talk to each other and discuss whether they can both support stuff. And they negotiate a whole load of things. And it's really timing requirements. And you really need to be able to deal with hot plug interrupts properly, so that you can actually do the training where you send them something, he'll send you a hot plug interrupt and tell you more information. So you need to have access to all of that. And that's where we decided, well, we can't do this properly in user space, in a 2D driver. Other things like suspend resume support, which can't do this properly in this stuff in user space. So we took the XORG 2D driver and we removed most of it, put it into the kernel, and we slimmed it down. It's a lot more small lizard now. It currently, all the XORG 2D driver does, is move from X rendering, so the X acceleration interface, into the hardware. It's pretty much like the Mesa driver does from 3D to hardware. The X one does from the 2D X interface to hardware, along with a little bit of extra stuff to make DRI2, 3D apps display, the final step of that process. But it's a lot simpler. And the other thing it does is X video. It's two features. So it's a lot easier to understand now. You can now actually, people used to say, oh, God, where the hell do you start looking in these drivers? And at least now, you can see this is just 2D acceleration. So far, the only driver that's really, actually, sorry, Intel and Nouveau have completely removed all traces of the old mode setting code. So they're pretty much Linux-only drivers at the moment in terms of, BSD hasn't quite figured out how they're going to do all of the features that the kernel requires. So ATI, we haven't quite done it yet. I did a demo tree. I just did a branch in my tree and removed it all just to make sure it could happen. But it was quite satisfying to see 70% here. Driver code just go away and not have to worry about. But we are hoping to do it probably in a few months' time. I think we'll do one more release of the mode setting code, and then we'll just rip it all out. I think even the latest chip support, there's no user mode setting for it either. So ATI have pretty much abandoned that whole path as well. And the main reason it's still around is I still used it in the enterprise code, and I just thought it was handy to keep it for now. Made my life easier. And then we have the question of, well, how do we join all of these parts together? And in the modern world, that's called DRI2. And basic DRI2 joins the components and makes all work. Now, the old DRI, and if anyone's wondering, that's like a lymphatic system. I just thought it was an interesting picture. The old world DRI was this insane thing where you had a big, huge super lock called the DRI lock. And if the 3D driver was rendering and wanted to do something, it would just take this huge lock and it would block x. And x would stop and the 3D would do its little thing and then it would release the lock and then x would wake up again and do its little thing and take the lock. And the lock would get passed around. If you had five or six applications, the lock would get moved around between them. The lock suffers from a lot of problems, like you couldn't debug inside x. Because if you debugger went into the lock, x server would stop. So you couldn't type into your debugger anymore. It's a bad plan. For ages, you used to be able to debug x itself, even from ssh, because it would take the lock and it would block. The kernel had this special signal blocker, which would actually block every single. Like even the signals you can't block would get blocked. It was designed around the fact that maybe your 3D hardware was directly banging on registers, your 3D driver, and if you killed it suddenly, it could leave the hardware in an undefined state. So it was allowed to always get to the end of the critical section and drop the lock, and then it would get the signals and die. But this caused a lot of problems. It's the same rule that we had for the 3D driver applied to the x server. And in a lot of cases, once the x server went into the critical section, you couldn't attach the debugger because the signals never would get to it. So you couldn't debug the large parts of the x server. So DRI2 basically got rid of the lock. The main reason we had the lock was we needed to share some information between the x server and the 3D drivers and the kernel. And the main reason, the information we needed to share was basically clipping. So you're drawing a 3D window on top of it, and you put a 2D window on top of it. You don't want the 3D window drawing over anything. So we shared the list of clips. So if you move the window around, the clips would have to be updated so that the 2D driver would know where to put stuff, or the 3D driver would know where to put stuff. What DRI2 did was, well, actually, the previous model in DRIs, well, we had one. So you've got 3D rendering a front buffer, back buffer. The back buffer was shared between all the applications in DRI1. And that was what led to the problem of why you needed the clips. Because to do any rendering, you had to not render where the other guy was rendering. DRI2 moved to the model of per context back buffers. So per app application back buffers, no, per window back buffers. So basically, in that case, DRI2, every app, every window, there's no one else to override. It doesn't need to know this shared clipping. And when it wants to display something, it would tell the X server to swap or flip it into view. And then the X driver, which already knows all the window and clipping stuff, would do the copy from the private back buffer to the shared front buffer. And it would do all the magic and deal with the clipping. So it meant that things got a lot simpler, because you didn't have to have all this magic lock and the insane lists of clips that were kept around the place. And it was a bit slower. And this is something people came out, oh, no, my GLX gears numbers, they're just not that fast. And you're like, really, doesn't matter. But it's still, compared to some of the other drivers, I think we've worked out you can probably only get to a theoretical limit of 3 or 4,000 frames a second due to context switch. Eventually you hate the number, because you have to context switch between the X server and the driver every time to do something. But really, nobody cares at that point. So there, the kernel is like the digestive system. It takes all the stuff that Mesa and the 2D driver get and pipes it down, digests it, makes it palatable, tries to clean it up, tries to extract some useful information out of it in places. And yes, we won't mention what the, well, there's a slide, but the kernel is the piping, essentially, in the model. It takes from all the graphics drivers, we basically put everything into a big buffer. So output of Mesa is just a big, huge command stream that needs to go to the hardware. The output of 2D drivers is just a big, huge command stream that goes to the driver. They all get sent into the kernel. And it schedules them, essentially. It's nice that we have plans to make it a bit more impressive, but the current scheduling is that you just get sent to the hardware next, and it just queues them up. So in some drivers, say, like in Radeon, we have reasons to not trust user space, because all of these applications are running as the user. They're not running as root, and then you're letting them send stuff directly to the card. So you have to be sort of careful about what you let them send to the card. Because there's a good chance if you just let them do whatever they want, they could just move your password file around by DMA-ing stuff into random locations of memory, or put UID 0 into your current task structure. Nice things that people love to try and do. So at least at the Radeon driver, a lot of hardware does just no way to stop it doing bad things. So you have to actually check the command stream that you're sent, and validate it that it's not going to try and do bad things. No, Keith's question was, do we have any idea if Windows actually validates this command stream? They've gotten better at doing memory separation. So the newer hardware really don't worry about it. But as far as we know, we don't think the binary drivers do enough validation that you couldn't get root by using them. And a lot of people complain, I was like, why are you doing all of this stuff? Because we think it's necessary. Well, they don't have to care because they're a binary driver. If somebody produces a hole in their driver, it would be quite interesting to see the reaction. I don't think they do quite as much validation as they should. As in, I wouldn't run them. But if you want to run them with WebGL open, people can submit whatever they like to your machine through the web. Solid. But yeah, the command stream verification is quite a lot of work. We have to go through pretty much every packet that gets sent from user space and check it's not going to do something evil. We took it one step further at Radion in an effort to make our lives a bit easier. We also check all of the packets to try and make sure they're not going to overwrite each other's video RAM. Because the video RAM is a shared resource, and you've got these objects in the video RAM. And you want to make sure if somebody's writing to an object, he doesn't go writing off the end into the next object, because that would be corrupt stuff. So we actually added a lot of support. Because we're already having to do all this parsing in the command stream, why don't we add something useful to it? So it would catch more problems, like some of these texturing off the end of their object, or some of these using writing to a buffer and going off the end. And actually, yeah, it was quite useful when we were doing driver development bring up. But yeah, since then, and we've managed to make things pretty stable, we rarely have a problem. And it's sort of turned into more of a hassle in parts, because to add certain features, you have to add support to the kernel for something. And then wait for that to come through the process before you can add it to the 3D drivers. It has sort of made the process longer. In terms of the other major functionality that's in the kernel, it's mode setting is now pretty much all in the kernel. That was the big deal, is getting that huge piece of code. And Linus, like, said, oh yes. Keith said something about, oh yeah, all our drivers are so much smaller. And Linus was like, yeah, my kernel is so much bigger. And the thing is, yes, the graphics drivers in the kernel are, I think we went from, I went from being a subsystem maintainer with about 5,000 lines of code to being a subsystem maintainer with about 100,000 lines of code. And this was quite a jump for ability, I was lost for at least two or three kernels, because there's so much stuff coming down. 260,000 lines of code now in the DRM, between the big ones being Nouveau, Intel, and Radeon. So yeah, we pretty much have the largest drivers of anything in the kernel. And yes, they're really, really difficult to keep stable. That's, we're trying, but it's the old one driver covering, in ATI's case, I think there's maybe over 200, maybe 300 PCI IDs. And PCI IDs is only one level. When you consider, if you've got a laptop with something, it's probably got a VGA output as well as the display panel. It might have display port output. It might have, then you might have a desktop with the same chip set, but it may have DVIs. Yeah, so there's so many combinations of things. And there's so many ways it can go wrong. Trying to keep a lid on the regressions and mode setting is one of our major tasks at the moment, that it's, Linus is keeping us in line, but it's difficult. So yeah, so the kernel, once it's finished with stuff, passes it along. And yes, I had to remove the picture, because if the kernel is the digestive system, that would mean the GPU hardware is something we shouldn't talk about. But yeah, GPU hardware is, yes, far too accurate. GPU hardware is something that you would like to think, this is, it's well designed, stable. You can be very reasonable about what will accept it, won't fall over. Sorry, that's not the case. And that's one of the other things. There's so many places in the GPU hardware, even when you have the specifications, that things can go horribly wrong. You get lockups, and some lockups are so easy to find. You're like, oh, reproducible lockup, you'll find it within a day, we'll pretty much get it, unless it's some one bit. In a magic register, that's not documented, it only documents outside of the company that owns the hardware. And even inside the company, they've never read that page. So nobody knows it exists. Or bit 31 in a 16-bit register. Never found that one. These are the sort of things that happened. And it's always that make me work bit. And then I'll say, oh, that just made everything all stable. But you could spend weeks looking for that one bit. Essentially, the Nouveau guys without documentation has possibly gotten an advantage, because they've never had to read documentation that was totally wrong. So they've got a driver that works. And reverse engineering it produces something that does the same as the driver that works. So they're only really screwed when they need to add a feature that the driver doesn't cover, or that is done differently in our driver model than in the NVIDIA driver. But essentially, once they've got something that does the same thing, they can pretty much get moved fairly quickly once they reverse engineered it. Whereas we sometimes trust our documentation to be too much, and then you start to feel the pain and torturing that I mentioned at the start. So that's pretty much where the driver model is. There's three big components and sits on top of that hardware. Can we make it simpler? I don't really think we can. And that's one of the questions we've got. How do I get into this stuff? How do I become a GPU driver developer? The answer, and people say, well, if we did more documentation, will that get us a whole in-rush of driver developers? And we sort of found the only way we've ever found people that will actually stick at it are people who, I don't know, are we just invest enough up front time to get started that you're not willing to stop, because you've just wasted so much time learning all about this. It's the best way, if someone was interested in getting into graphics hardware, is probably the most accessible bit is the 3D bit at the moment. In terms of if you know how 3D works, if you're willing to read OpenGL or write OpenGL applications and have read like some of the OpenGL books, you'll have at least got a knowledge of how that sort of system works. And then it's a matter of just running applications on your machine until you find one that's broken, which that should take about five minutes, maybe 10, and debugging it and going through the driver and seeing where it could go wrong, looking at the shaders, looking at what it produces for the hardware, seeing stuff like that. Other areas like mode setting, mode setting's not that interesting. But yeah, that would be an area for people to look at. So I'm just going to go quickly through some other little bits of the future. So Wayland, people have heard about Wayland. All the work we've done moving stuff out of X and moving things around has pretty much been to enable some sort of future where X doesn't really matter. And Wayland is the first attempt at making this future happen. I've got an Amoeba picture because pretty much Wayland is a single cell application. We've taken all the separate little bits of X, like the window manager, compositing manager, the X server, and they're all going to go into one process called the Wayland compositor. It's simplifying the craziness of the X architecture diagram, arrows going everywhere. The idea behind it is it's more like the Mac OS type display server. In terms of is this the future? I'm not willing to put my money on it yet. I think it's a future. I'm not sure it's going to. I'm not saying Mark Shull works his wrong. But I'm not saying he's very right either. I think if I want to do Run Wayland, it might be about five years from now. I'm not saying it's going to happen in a year or two. There's a lot of problems. It's a big project. X took a long time to go horribly wrong, and then it took us a long time to get it horribly right. Maybe we've learned, but I'm not sure. GL support going forward? GL3s will be a big step, trying to get intolerant. A lot of work towards it. There's a bit of a patent problem with SGI due to the fact that they have explicitly said they have this patent that GL3 implementations will infringe on and that they won't let open source people have it. But there's possibilities to do similar things to the FFMpeg type thing where you distribute it with the source code when it turned off. And if a distribution has a willingness to do it in there, take on the ability to turn it on. And that's possibly what we'll end up doing, because it's unlikely they'll care so much about the source. It's more likely they don't want to go after somebody distributing it, or if they want to go after anyone. It's just probably safer. But yeah, the plans I think would be to try and get GL3.0 as fast as possible, possibly by the end of this year. But I don't know, it's gonna be hard. It's a lot of work. The hope is once we have three other things get quicker, but we're playing catch-up from about five years behind. And I don't think we can do it in that quick time. And at the same time as we're catching up, they're hammering ahead with GL4.1 and adding new features and pretty much following DirectX. So yeah, the GL3, GL4 support, it's a good way away. People will give up, but you can sort of get partly there. GL has now, you only have extensions. So if GL3 is made up of like 15 extensions you have to do, you can implement 12 of those extensions and get most of the way. And most applications should be checking for the extensions and not the version number. Because with GL2, the version number was what mattered. With GL3, the hope is that the app writers got the message. But we've got embedded, yeah, embedded ARM GPU. We had a talk on Monday at the MINICONF. It's an interesting space, but from an open source point of view, nothing's really happened yet. There's lots of talk, but how long it will take before some traction happens or something happens. I'm unsure. I would love to believe we would have something in the next year or two, but yeah, it's an ongoing battle trying to get ARM GPUs. I think it's the next battlefield because X86 has mostly been either, they've given in or reverse engineered. So multi-card, we used to be able to do Xenorama, multi-card things in X. It hasn't really worked well. It never worked well, but you didn't care about them because you only had 2D, but 3D would never have worked. Things like, I think that what it needed interrupts never could have worked. So multi-cards are something that I'm personally starting to work on now and I'm trying to get back up to some useful level that we can actually ship. You can plug two different cards into your machine and it won't just ignore one. Windows took this to the payment just gave up. So if you look at Windows 7, if you plug the upgrade notes, it's like, if you have two different graphics cards in your machine, after you upgrade, one of them will no longer display. It's like, unless they're of the same manufacturer and the same, you know, close model, but if they're separate, not a hope. Switchable graphics. There's a lot of laptops out with Intel NVIDIA cards in them. A lot of them went AMD, AMD, Intel AMD. I had a bit of a demo. I'm not sure if I'll get to do it, but it's not a great demo. But in the kernel at the moment, we have a switcheroo. You can log out of X and it will jump from one card to the other and X will restart on the other card. It only works for open source drivers. I don't have any way to work on NVIDIA Binary drivers like nothing I can do about it. They can come talk to me and tell me what they want to do, but so far they haven't. I've started work and I've pretty much got it going to the point that I can dynamically switch while X is running. So you don't have to log out of X. Mac OS never bothered doing that though, so. I have a demo of that working here. The follow on to switchable graphics is offloading graphics, which is Optimus. That's the NVIDIA solution. So instead of switching completely from one graphics card to another, certain apps are run on the second graphics card. So you just pick one app and offload it to the second graphics card. USB hop plug, plug in a USB VGA. Fail, horrible fail. Even if you plug it in before you start X, you still have to edit your Xorg.com to make it do anything. That's one of my other personal projects to try and get done. People heard of Crossfire SLI, the ways of using 2ATI or 2NVIDIA graphics cards to make your games go faster. That's another thing that we just completely don't have any ability to do. We're working on that as well. So two projects that I'm starting to get going to solve nearly all of those multi-heads to Crossfire, to USB hop plugs, problems are. One I've called Dynorama, because it's Xenorama, but dynamic. I merged my words. Dynorama essentially is a hot plugging layer. So for Xenorama, that's something I've started working on and I have the demo of here. That's used for switchable graphics, USB hop plug and they're the main things it enables. The other one is Prime. There's a dissected Optimus. Optimus is the NVIDIA solution, so our solution is called Prime. Prime is basically a graphics object sharing in the kernel between two different graphics drivers and that's really useful for the off-loading graphics. So your NVIDIA card will render something and give it to your Intel card and it's also very useful for doing dynamic switching where you want to just give objects from one card to the other without copying them and it's also quite useful crossfire in SLI. So I did have a hack of a demo, but we can ask questions and I can see if the demo runs at the same time as I answer them. So questions please. Dave, you mentioned when you brought up the multi-card or multi-head topic before, something that I've missed in recent iterations of the X servers and things is the old Zafod mode. Do you have a comment at all about whether that's officially something that's in the history file or whether that may actually come back? Currently the Intel driver is the only one of the three major ones that don't do it. I had to reimplement it in the ATI driver due to a customer and the NVIDIA driver guys Nouveau implements it now because it's actually not that much effort when you've got Randa already to do Zafod on top. The biggest problem we have with Zafod is because nobody's using it all the time, it's nearly always broken by the time you do a release and then you have to remember to test it and go back and fix it because and that's probably the bigger problem. With the dynamic Xenorama stuff, that maybe we may actually end up that you're always getting something like Zafod, you know, that's what it's sort of heading towards. The hope is that we would merge that whole thing into just one consistent interface, whether it's one card or two cards. Talking about the RI2, you said essentially you need to do a round trip to the X server for the final composition. Do you have things like bypasses for full screen apps? No. Would that make sense? We've got page flipping, but it still has to go through the server. Not really, because if you're on full screen, you'd have no lock. There's no way to stop the guy keeping doing what he was, but yeah, the last time we tried that, I just, yeah, the kernel code. Once you start putting the clip lists into the kernel, you've probably lost. But yeah, there may be a way to optimize something like that, but it's, again, it's not that. The problem is, you know, if you're running at 4,000 frames per second, your problem isn't going to be that you needed to do that. It's, page flipping is essentially a good enough full screen optimization. How are the BSD guys liking all this stuff going into the kernel? Yeah, no comment. They are, they are. OpenBSD guys love the idea of KMS because it fits the whole security model because X was always violating that, but they haven't loved it quite enough to do it, but they at least have acknowledged that it was a good idea. The rest of the guys have mostly just been saying, why won't you keep our drivers working? Eventually, I'm sure they'll pick it up, I hope. And where are things going with video playback offload into the open source drivers? Yes, Intel have started doing stuff on some of their chipsets with VAA API. There is a VAA, no, it's VD-POW. I think someone has started working on XVMC Gallium stay tracker and he hasn't working on the latest AMD cards, doing MPEG 2 and IDCT. Yeah, he's got IDCT working. He's now working towards optimizing the driver so it's actually usable because the R600 Gallium driver has no compiler in it yet, but that's the plan for most of the non, for put Nouveau and Radeon would be to use some sort of shader-based thing. AMD have not yet figured out how they can tell us how the R600, R700 graphics hardware accelerates. Up to R500 AMD don't, R600, R700, they can't tell us how it works because when they designed it, they put their DRM layer very tightly coupled into their video decode layer and it would mean that we could, someone could break the Windows DRM which would end everyone. Just quickly in the background there, you'll see there's a root weave. That's the Nvidia card I'm currently not running on and that would be the, oh yeah, there it is. This is the Intel card that's currently, so I can flick back between the Intel card and the Nvidia card that are currently in this laptop. Interior, well I'll do this first. That's pretty soft for rendering. Damn. The only way I have to show you, of course, that I'm not cheating is GLX info to say I'm on the, yeah so in there you can see Ironlake Mobile Gem. So that's the Intel card running in this laptop. Interior, damn. But yeah, it would have shown you that it was running on the Nvidia card and I switched it over. And that's the Intel card doing nothing now while the Nvidia card is displaying the extra. But it's taken a whole of the accession and moved it from one graphics card to the other. This was non-trivial.