 We actually presented some preliminaries somehow, the end-day acceleration, which today is quite complete. Last year we already had most specifications we must have made with cars. Meaning we were... last year was like, oh, we know how to do that. And Geolex Chills was running, so what's going on there? Well, the first thing is we still keep this process. You know, we've got this process of trying to build a bigger and bigger community of developers around these drivers. To me, that's very important. Well, as you speak around here, there are always further down people working on this. So to keep the ball rolling, we've got to evolve new developers in the time because people come here. So, well, we certainly try to make this as much publicity for the project as possible. Which means, of course, you might all know that TI and DC, which is a big meeting, have somehow been with you and have never been with somebody. There's an update on the project on the stage. Well, this last week has been on this and that, so it gets people, you know, actually seeing what happens, other than by having to check out the Geolex Chills and try to compile it. We've got to associate it with some new sites and we've come to make this one of them. We've published an article on these great news. Actually, it's currently available for speakers there. At the moment, we're still very focused on, you know, working through IOS and this very convenient visit. It takes pretty fast and it's not like emailing everyone while chiming. IRC has reached a kind of compromise quite quickly when it comes to technical issues. So it's pretty convenient to start with. Since we're still very much in development driver, well, we've gotten a new spoken policy that broke until we decided not to adopt it, which we apply fully when we say we've got hard on our own for some support, and we're not going to say that we get this support. It was not so well-working out of six months ago, but through continuous testing and years of support and actually things did not work as we wanted to expect. Well, we were able to fix that. So, I think it's very important that it broke until we decided not to adopt it. So, moving on to the hardware product. I'm going to introduce the hardware feature once again. I'm going to go into a little more detail to explain what actually justifies the choices which remain in the design. So, we're covering a ten-year time frame. We stay under four, which is a little bit late. Then we're covering the end of 15 hours of hardware feature. So, it's a bit in perspective. For example, look at the region drivers. It's pretty big for the region that we have said. We know it's under the same time frame. We've got, most likely, we're going to have the same issue covering all this hardware. So, hopefully, there are some similarities between the cars, and we can leverage some common code people. But, although there are some differences, we're going to have to deal with all the 3D handling, which I'm going to show after this. Which, in principle, we have to write the application. So, the nice thing, we've got hardware context on the car, which means we're not going to bother with a lot of the abstractions going to be written for the car, which actually both storing and restoring the context is things. Which is pretty complex, and has to be done with the DRS all the time, in real time, in switch applications. In the NVIDIA case, we've got hardware-based context switching. So, the cars will actually expose numbers to common buffers. Well, which common buffer gets the time scale, just like round-robin cadmium. And once the time scale is up, all the other context is mixed up, and the state is put on the car, and you can do it for a number of milliseconds. So, it's quite simple, you're going to have to wait for it. Well, it's very nice, yes, on many, on many cars. If you have an N4, it's the oldest one you've got in the NVIDIA. If you go every 10, you've got a N32, and you can go every 16, a quarter, a quarter, a quarter, a quarter, a quarter, a quarter, a quarter, a quarter. Yes, yes. Actually, it's not. We'll keep one for the trouble, one for the accuracy, maybe one for the speed, even then, one for the speed of the application. So, yes. And if we do not have this, we still have this. We can actually ask the cars to go, we can test, we can test it for development. We've got a lot of protection. 16 just in case of the standoff in TNT. We're not getting the limits. Yes, but it's true that the other way of connection, we test the wheels well, and the panel can be used for all the push-ups that we have in the U.S. that happens. But as far as vertex data is concerned, the overall value for now is up to three. From 10 to 10, you get fixed vertex response, so it used to be called TCL on the roughly delayed, that's when you consider it's not really flexible enough to be called. The first generation of vertex program here, which is available, which is very nice, because it's unified, so we can pretty much show the same code in those two times as fast as we can. On NB40, the vertex processor was bred in, and then in NB50 it actually merged. The vertex and the vertex processor are the single base space which I use. As far as texture, combining and programming programs are concerned, it's a little bit more complex in the time because it goes very fast, so the new APIs are moving towards a lot of generations, a lot of changes in the generations. As far as the TCL capabilities is concerned, we use that hardware overlaid until the NB30 actually online, the vertex processor and the body cards, you know, have your own believe it. No one's got this card, most of the NB40 cards do not feel hardware overlaid, so we pretty much have to do video on that by using, well, pretty engine and programming processes that we're using. And as far as TCL capabilities is concerned, it's just a little bit more specific. Like Xambra, when the box is combed, the converter and T and DS encoder become heavy. Say, hey, I've got TCL and design, but it's not basic. But starting from NB70 actually, it's just a very nice, mostly unified TCL capabilities. Which means these cards might not really get too late if you see two of these people. We're not really that much interested in laying all the very difficult steps together. But let me show you if we'll do it. So now, we're moving on to the reverse engineering part. So, the hot tool of the moment is called MMI Trace, my word about it. It originates from the new project with us. You now have to believe that out of its own. What's the idea of this tool? It's a tool that's aimed at tracing inside the terminal what happens. You want to know what hardware registers touched by its binary driver in your Linux kernel. You can use this tool as a quick inspiration of how it works. It's very simple. You've got a track called the IORI app tool, which basically is used to map the terminal by its base to not just the claim of the file. So you track the code. Next, we just remove the page matching to this array. So the next time the binary driver tries to access the array, it will trigger a page fault as you expect in the more architectures layer. Now, we map the page. We step the single instruction. And then, we remove the page again. By stepping this single instruction, we can actually, before stepping the instruction, you want to know what registers were assessed, were assessed, and what was pushed by this one. So in the end, we are able to produce traces of register assessed of any binary driver that is used in Linux kernel. So you can imagine that this project's got a very wide scope and many other specific tools. And yes, it's getting used because we feed my Wi-Fi guys. They have binary feeds in their Wi-Fi driver, and they are working on the real estate engineering, and they use this tool as well. Sadly, it got broken in two-sixth of a kernel stack. That's because we used a hook that was not really widely used by anything else. But this tool, I did, it turned out to be better. We wanted to get ourselves a support tool, but we didn't really follow the way it was going. It made a mistake. But we're not aiming for mainline kernel inclusion because that basically shows that this stack will not happen again. This also shows that next time we want to reverse-engine a binary driver, every single user will be able to have it as a default in the distribution to have MMI trace and do reverse-engineering of a piece of hardware again. So I think spreading this tool is quite interesting for us, and that's why mainline inclusion is very important. So we might be aiming at two-sixth of a kernel stack, but don't take my word for it. Next, we've got Wolfgang M&T, which is a tool that attracts user-space access to MMI registers. So it works mostly the same as MMI trace, but it's just a user-space. Obviously, you can use it as a source, so you can actually reverse-engineer a binary export user-space driver. So we can do what's between the two of them, because that's in the user-space as well. Finally, Wolfgang, which is an old dog, you might not know about it. It's very basic here. This is the tool that Wolfgang made two years ago. It's just not the people. You know, the binary hybrid driver, not the people inside the open-gear application space. So this renewable is just an open-gear application. It finds the people. It looks, it sends a couple of open-gear commands. It looks that the people change, that they span. So by setting this blending mode, it's just changing the feature. So it's as simple as that. If you repeat that, you get this single open-gear functionality, where you can pretty much reverse-engineer as your own 3D pipeline with that. And obviously, it gets regular and new tricks, which are a big open-gear category. So, moving on to 2D support. So where are we now? Well, we've got simply the acceleration for NB4 because of hardware repetitions. We cannot do too much. It's right very hard, but... It's in the NB50. It's also very simple, but that's because we lack hardware at the moment. I actually plan to change that. What do you mean by setting the speed? Oh, accelerate the copy operation, solid field operation, load and download. That's fine. So that's... Actually, that's what you get in the radiance for after NB chips. Radian HD. And then... Yes. So then, if this is the only choice... So... I mean, why don't... Why... Why... What? The question is very early on, we've got... We decided to ditch XAEA because we looked at... We had the two implementations at one time in the cargo and home, and we looked at the two pieces of code, and one was XAEA, and it was pretty big. It was pretty complex. And one was the XAEA, so it was small. So... Of course we get lower performance than we expected in the future. So... But this is... All right, this is a bet on the shoes. But that's the question. You know, we are directly willing to see the lead in that one. So... We have something to work out. That's... That's a good question. We didn't really want to... In both development times, it was something that we'd get through sooner or later. The nice thing about P8 days is that you can actually rate X renderers eight times. Yeah, but it's not in the very end. So, are you not using it yet? Yes, for all these cars, we are actually doing so. Okay. We didn't want to, like, you know, one fact that you get faster and faster than the other. It's getting very complex to be working on. We tried to make this as simple as we could. I think that's very important, when you're in for that ten-year time. So, yeah, this car can get pretty much all the operations you're going to need, or you can just go back to the original. Of course, as you were discussing, E&A is not yet up to speed both, for example, the car is not really as fast as you would hope. Hopefully, this would be quite soon for E&A, but as far as implementing the hooks it's concerned we are implementing this. So, we also get a performance glitch from synchronous outputs and none of those, even though we've been lifting the simulation wheels because of all this stuff, but we still can get pretty hard on this. This actually depends on doing a proper TTI, so it's more of a long-term goal. So, actually, working at the vacation of third-student development vacation and you work in the X-ray layer, so we cannot say that we're faster than the primary drivers performance consumers, but that's done through braking, you know, the upload of the frame with the rendering, which is pretty crazy. People have these two stages together which is pretty crazy. And we've got another adapter on engine 13 and forth, which gets you a better filtering, so we've got these things that got it doesn't have the better speed but it's got the better quality, so if you want to watch movies which involve high end of screening, it's pretty interesting. And, yeah, women's matches with life, you're close and forth, it's pretty crazy. I just placed an engine that has got better speed than a musician from his life. So, another thing that is getting more and more important and it was actually the reason it all started in the first place I had begun with, it was two and a half years ago or something, I had begun to write a jazz part to adjust my exhaust, so we've got something to wear there at the HCI talks you know what that's got? It's Aidan Giasca, so we've got you know what's got to be Giasca, so we had to implement an inspirator for this and ours was actually based on a tool printing application around from the V.O.S. driver which had this amazing for a long time and recently it was revised by Steward Sears and it was found we knew this from the beginning but it was just found that it was getting really, really needed some proper mode setting especially with all the word outputs, it's really hiding a lot of things, you know the difficulties around the mode settings stuff, so this is a very welcome addition hopefully to be able to code boot the cars as well one day not yet the case, but for example, people who do not want to have an X-Late simulator in their X, it's going to be able to code boot and read their cars with this so we're thinking for a PC people that can be convenient people so R and R will continue so yeah, we support that, mostly less than the cars we should get but you will have to change the hood as I said, the older one was more difficult we've got the only three configurations as we would expect, a lot of R1 and R2 and still there is a static form for location issues which means you have to pretty much put in your X or configuration the maximum size you ever want to use even if you have the same screen we made for the old version but that's not the only addition on our side you might have to work this out for me so now, moving on to the meat, the thing is it's really hot in there so bottom down bottom down so, the old DRI model we are actually implementing the most DRI style driver, mostly for Grand Chels XS and it was something like 25,000 lights and it required 25,000 lights, which is a lot of work inside the driver each driver actually had to use most of the OpenGL back by itself so drivers get the big things that could be factored in our apps so it was still a sub-optimal so we've got from test and graphics a nice architecture which we'll give you if this is much in common as possible you should intermediate that so you can pretty much have whatever graphics API you need and you can have very simple drivers so for the permanent comparison we used to have this 25,000 line DRI old school driver and now we've got the 4,000 lines ND4 driver which is working as well for DRI 1 as far as ND10 is concerned the start of implementation should be pretty complete because of the 4K settings because the start is much simpler the implementation is 2,000 lines so we've got the mostly working 3D driver in 2,000 lines which is great as far as maintenance is concerned this is new one so you're probably going to ask but if we use a straighter implementation in the middle of the pipeline what about cars that do not have this series it's very important as well because these cars will get some additional intermediate implementation so we've got just extending all the cars is just as simple as adding additional instructions to the permanent project program which basically mimics the behavior of the old speed so you get basically passed down through the pipeline programs that are not real fragment programs but simple things that describe this old old and shared extension just using instructions so this design can actually extend to support these old cars as well this is what I'm doing at the moment I'm going to be 10 drivers soon and be able to show you that because I think this is still important to support older cars and gallium in my opinion is too important to get for fragment shader supporting only cars so I think it's very important to extend it for the cars as well so our current gallium development before the driver is somehow working so yeah you're going to be one of them actually two of them are going to be one of them we have been 10 and then 30 drivers are in the development you're watching the gate you can see that I'm porting the NG35 right now I'm not yet importing the NG35 so what does the future call wow a big one the TTM this is more the memory management it was just internal memory management we would just be able to replace our API and say well we already have our own memory manager so we could just switch with the TTM but it's not as simple as that because it will manage memory it's also going to move the memory as other applications require so something the application uses to make video memory is moving while the application has to know somehow so that's the most important one it's not really possible to have the application really know so the solution is another one the application it's coming back first to the kernel and tells the kernel where the offset actually live and the kernel is still what we call relocating of our offset fixer it will override the offsets with the proper offsets for each resource so since the kernel knows it has to do with it there is to achieve this there is something called super out of the TTL it's not that super in our case other drivers do a lot more than we do in this but we're going to have to have this as well so we're going to have TTL is not really easy especially because you have to notice the kernel that in gentleman's buffer so you've got a big common buffer it has to say there you have offsets which need to be fixed by you by the kernel because you're the only one who knows where one piece of memory so this is the job of the super out of the TTL among other things of course but in our case this is mostly the job well the DRI2 it's still very much in the air because for us in general it's been pushed but for us it is very much in the air but hopefully it shouldn't be an easy one because it's got a couple of purposes which we actually never had these issues we're trying to remove the big graph which is a graph that was preventing application for ten years ago which was quite killing the performance of this data it's also trying to remove the short area so in the old design the kernel, the X server and the DRI applications the FIDI application they all have they used to have a single piece of memory which was sure they could write the bit there and say hey I'm doing this and I'm putting this on this piece this was particularly useful for what we call clip resemblance which is a major thing because when you actually do 3D acceleration in your X server they basically have the 3D application handing a 3D buffer but then you all know that other windows might hide if the DRI application doesn't know it will copy overwrite over the rest that's the major issue and that's why DRI 3D services you all see on this piece of demo where the cube moves but the GLXGS does with the cube services this is really difficult one because you have to look at only one parameter well in our case it's very driver specific in our case we're not really sure that's why I've said it's been very long in my life well actually you can have DRI too and keep locking mechanism it's not explicitly prevented but the new design lets you have a luck less it lets you have a less server real it lets you do things but it doesn't force you it's pretty it's the same for the shrink buffer you might keep it as well if you need it the design does not treat on this but it helps you actually the old design prevents it but at least the design doesn't treat on this that's the idea it keeps flexible in our case don't have the idea that you are part of the DRI too because all DRIs are suspended exactly like that you are part of the DRI yes mostly you are part of the DRI yeah we we don't know yet there's just additional stuff it's the swap buffer we don't know yet where you know we've got three components we have the space components and the 3D DRH components we're not sure what if the swap buffer is copying we're still if always impossible because there's a very big performance in fact to do this choice we're going through a lot of these general mode setting everyone talks about this Jerome is waiting to get this tomorrow how he's doing this we want to do this first of all we need to stabilize our R&R 1.2 interface in user space just the different stuff in user space is the different stuff in general space but then once it's stable we want to move it in the general mode except this involves having the best parts as well inside the general mode this is going to be a first I think it might work actually so that's what we assume this is very much a work in progress it depends on a lot of things this is why today it's not really happening if you want to do proper suspend and resume you do it all from the current which means that all user space components have to become pretty dumb about the current state and what they expect from the current review as soon as we're there we'll be able to do very easily and now it's really working just as fast as we can as soon as we do it the better it gets and then we have to save and restore a great experiment seems to work somehow it's very hard to to do it it will take hopefully the moving improvements inside the general mode as fast as we can if we do not move enough stuff inside the general really the general can be the only entity knowing having full access and understanding at the heart if multiple entities are imposed to assess the same piece of hardware that's going to become very quickly very complex so another question will get asked a lot about pretty much very often we change our model most immediately really well doing a real release and merging into main and general mode merging the ERM into main and general mode the product that we stabilize our API with the ERM which is going to change because I'm turning it on set so it's also going to change because of the ETM and super-hard IOS city so this is still one of the definitions that depend on all the steps and this kind of things much like suspended region we might get those two at the same time because those actually have the same requirements so we do of course we decide to stabilize in the current interface but then we get by the Linux to maintain this interface forever so not doing it's not really in our own interest at the moment