 and it will be 8.5 at 15.30. And then you can sit on that. I'll help. Help me. Please help. What did you bring? What's wrong with you? What's wrong with you? Okay, so... So, can you jump? Great. So, hello everyone. If I start talking quietly and you can't hear me, just yell. And I'll start speaking loudly again, so... I'm just going to try and give you a quick shout-out of kind of where we are, where we're going with open source graphics support on the ETI. Okay, so let's see. One of the things everybody kind of knows first. So, on the back, we put out the first specs for the display mode setting part for 5x and 6x parts. The first docs we put out were for the desktop chips. It turned out they were missing a lot of the interesting blocks. So, we replaced most of them with the mobile specs, which turned out to have all those blocks in them. Anybody who's looking at the documents, just read the mobile ones. Don't bother with the desktop ones. We left them up there. But the mobile ones are kind of all you need. Going forward, starting with, I guess, internally we call them the 620 to 635. And externally, they're the 34, 15, 33, 3670 or something. The display controller there changes a fair amount. My guess is the expert will talk about that a bit. That's really to support display port. The big thing there is display port puts another set of clocks and packets in between the ins and the outs. We had to restructure the way we abstract the blocks to let you do with all the different clock rates stacked on top of each other. So that all changes and Luke's cursing it and everybody's working through. So, we should get documentation out for that soon. We've got the interesting guys who've got it today. And it was just recently, and they're working way on that. There are more changes coming down the pipe. They shouldn't be as drastic as the changes from the previous 6XX parts to the 620 and 635. But there's, I think, two more generations of display controller coming down the pipe with more changes in that area. So we're trying to find a good way to provide direction without blabbing out here. Here's what all our unreleased parts do. So, we're working on that. We've got display port chips that support in the chips, but there's not much out there in the way of displays except for that big Dell monitor. And everybody's still figuring out how to do the display port certification. What's actually happening is we wrote some internal tools that we use for our own development. There's third party tools that are supposed to be out for certification of the display port interfaces, and they're not on the market yet. So, everyone's calling us up and, Hi, can we have your internal tools? So, we're cleaning those up and getting them up to us. Display port is there. What we're focusing on right now is just for the new chips getting the existing display functionality. You know, the analog, the DVI HDMI, that kind of stuff getting out working. And then we'll go back and do display port as a next step after that. So, to the acceleration, it really hasn't changed since the R200 days. The programming model, even the performance hasn't changed all that much. Memory buses are wider and stuff. Fundamentally, it hasn't changed. So, we're not planning to do any more documentation there. I am trying to get the old R200 programming guide re-released because it's a nice intro to how it all works. There's also some information in the 3D docs that we put out last night. It's got all the command pack and formats and all that junk. So, the kind of, the details of what you need, a lot of them are covered in the new docs we put out last night. But the old programming guide is a nice way to kind of pick up and learn how it operates and how you use it. So, I'm going to try and bring really sad. Starting with the R600 X parts, we actually took out the 2D engine. So, there's two, there's a circle being two ways to program the 2D engine. One is MMI out by clenching registers to make it do things. And one is through the command processor, where you put in command packets, the chip GMAs them up, the part and executes them. On the 6XX parts and under the 780, which is the new, the MDX10 integrated part we just got coming out. There's no 2D hardware, but as long as you use command processor programming for the 2D engine, the command processor will interpret those command packets on the 3D engine. So, if it works on 5XX, it pretty much works on 6XX. There's a couple packets we dropped, but as far as we can see, we don't use them in the open source drive. Having said that, I'm sure we'll be dodges. You know the trick, and this is one that the people are still going to use before. You need to set up a buffer full of commands, which basically put the 3D engine in a known state. And whenever the command processor starts processing 2D packets, it fires off this command buffer, resets the 3D engine, uses the commands, and it just puts the 3D engine back in a known state. Past the 780, 2D is gone. Okay? No hardware and no emulation. So, the emulation is a good quick and dirty way to get running today on the current parts. But going forward past that, 2D is gone. It doesn't really matter, because if you look at the 2D acceleration, things that actually do anything, they'll use the 3D engine anyways. More than half X, it needs a 3D engine. And basically, the stuff that anybody uses is 3D. So, nobody really cares about 2D anymore. We need it in there for some of the apps, but it's one of the things where we're thinking quick and dirty is the way to go. Okay, 3D Docs for 5XX came out last night. 6XX we're working on. My guess is a month, roughly. What T-Core is, so I have some free advice for any other hardware vendors thinking in the open source field. If somebody offers you an internal utility and says, here, it'll be easy to clean up and it'll be useful to developers, and it won't take any time to clean up. Run. We've been cleaning this thing up for like five months now. And honestly, if it wasn't for the amount of work we put into cleaning it up, I probably wouldn't bother releasing it. The real value of T-Core that we don't have covered any other way today is it covers memory manager setup that we need for DRM. It covers ring buffer setup to a quick man processor in the IDC-T engine. And it's got some other useful examples. Even in the early days, I think the radio and HD guys probably took two weeks to get past the point where all the stuff in T-Core was already running. So, anyways, we'll probably go over and release it. If the lack of T-Core holds things up by more than a date, we'll just strip out the stuff we need for 5xX DRM and push it out separately. I'm determined to release it just because we spent so long on it. We're considering sample coverage. Yeah, I talked before, I think at XDS. The plan we were looking at was not so much documentation and more sample code on the 3D side. We're still thinking about sample code, but right now the sample code is about 6x as big as the driver we're trying to show you how to modify. So, not sure there. We're not starting to deal with sample code. Initially, we thought it would be quite hard to get documentation out of the door. You know, the sort of programming guide type documentation. When we actually went through and tried to do it, it worked out better than we expected. I guess you've got to see it. Yeah. Yeah. Oh, exactly, exactly. Yeah. Okay, so, at the main point, in case anybody's asking why this documentation does not come out of the box. Our development model, we've been kind of divided into different groups that work on different components of the chip for a long time. And we decided a long time ago that the first thing we needed to focus on for engineering documentation was making sure the hardware design itself is well documented and the software design itself is well documented. And we just co-locate the hardware and software people who are working on any given block. They sit in the same office, their cubicles are interleaved, and we hope they talk to each other. And it generally seems to work. What it means though is, if you started, we've got hardware here and software here, you've got documentation here, you've got documentation here, but you don't have a lot of documentation required at the end of the fix. We did it with the groups. So as we get more geographically dispersed, I'm guessing you guys have already had to deal with this documentation between the hardware and software groups is going to be more important. So... Yeah. There's so many good arguments for both and I still don't know which is best. Yeah, I know. But one produces documentation and one doesn't. So there's an argument for that. So anyways, we've put our software processes, so the material that we need to make good open source driver documentation should be easier to come out. We're looking at making tweaks on the hardware processes as well, but they haven't happened yet, but they're in discussion. And of course, what everybody wants is software people to look to hardware people to produce a nice piece of good. And... We'll see how that works. Okay, driver status. Grade NHD supports mode setting on 5XX and up. 626, 635 and 780 are in process. They've all got the new display controller. So it's a bunch of work getting in. One of them is running, one of them is running, getting the other is running. It should be pretty straightforward. Most NMIO based 2D acceleration is in. And so the next thing is just getting CPDDR support in and then all the 3D stuff should just come out of it. So the initial support for the display controller, he said this, and it was, the existing interface is not a display port. Having said that, the way it's looking, we've got everything figured out enough to do the existing interface so the display port should be easy. So finding surprises of the existing products. An example here is just, the last week or two, we found like a million emails back and forth. There's another block that we... we believe nobody was using on the chip, another display of the block. And we found about half the 695 boards actually use this block. So there was a lot of head scratching all around. And then the block controls are all sort of interleaved so if you program this block, that block almost works. So anyways, we've been passing now, I think Alex figured it out last week. The existing radio driver went up to 4XX, picked up out of Biosupport. So that gives it 5XX, 6XX support and lets leverage some of these existing accelerations for them. So sort of today, 2D 3D work is really happening more on radio and radio and HD to catch up here. Alex's texture video running on 3XX so it looks like moving that to 5XX, 6XX should be pretty easy. It's basically just processing all the shaders. That's one thing I should mention. Talking to end users and VHR products and from all the emails that come out of Intelli, I think they've got the same challenge there. There was a shift from having a lot of video processing hardware in the overlay to doing more of it with shaders. And so in our case, basically everything up to 4XX has the old video processing hardware. The video overlay with the video processing in it, everything 5XX and up. XV is handled in shaders. And it's about 945, 965. Ah, okay. We have similar discussions. Yeah. Yeah, I think we're all pretty much, I think the whole industry pretty much walks out about the same time. So it, uh... Exactly. I mean, you can do so much more with 3XX. Okay, so that's pretty much it for that. So, um... I don't think everybody knows this, but fundamentally, all focus and all the attention is being here. I think for the next month or two, you can see more of the focus shifted here, which is really the 3D side and 2D commands going down. Again, if you're here as well. One of the things that gets difficult explaining to someone who's new to the Linux world is half of what they call 2D acceleration runs on the 3D engine. And the first time around, that's kind of hard, so many lives on it. I mean, I tried to help the video player and it all worked out and I gave up. The main point here is there are, there have been multiple X drivers over the last while, Riga and HD and Riga being the main ones. We don't want multiple here. Okay, so, one driver's good? It is. Most heavy hardware with someone new for the 5XX. So the different views on how best to handle that. My personal feeling is that having multiple drivers right now is a good thing. We all, I think everybody agrees we need to get to one code base, but right now I'm seeing useful things. I'm seeing different approaches work better different ways, information pulls back and forth. I'm thinking in the next few months that it's going to stop being useful, but, you know, I don't know if it's going to be useful. Probably that's what you're going to get in the app college. So the mode setting is only starting with 5XX. The rest of the hardware doesn't change as much. There are big changes, but they're not at the same point in the evolution. So we want to try to avoid forking the rest of the code. So basically the mode setting is multiple implementations today. Getting them video acceleration. There would be multiple copies of it, but we'd like to keep the code as close as possible. So it only kind of has to be supported once. If it gets fixed here, we can fix it somewhere else. Three in DRM. They're separate components from day one. Let's be with one implementation. So as we get more complexity going in, the driver's regression is going to start to be more of an issue. We're setting up building tests and working out with everybody, but we're putting new resources to do some building tests on this. One of the things that I think we found from our own internal development activities is it's a whole lot easier to fix a regression if somebody can say, this change broke it. If all you get is, this doesn't work anymore. Did it ever work? I don't know. That's a lot harder. We use AtomBios internally, and all the close-ars drivers leverage AtomBios. So when we ask questions internally or in design groups, the answer is I'll come back in terms of do this in AtomBios. So Alex works at Newstaff in AtomBios, and what that means is that sometimes things can pop up in Radeon faster than RadeonHD and we're talking about ways to avoid that. Don't reach too much under that. Okay, so here's the picture. This is where the display control changes. 3D input changes here and here. You know, different pieces change at different points along the pipe. So one of the differences is there are multiple components, so you can have multiple limitations here and single limitations there. Unfortunately, the chunking of functionality into components does not match the way that we evolve functionality in the chip, so there's always going to be stress there. And again, the challenge is always the X driver, because it's got so many different functions that it's clumped into one block of code. So I won't go through this in a whole lot of detail, but fundamentally, between CoreXX and VibaxX that's where this is a big change in the display controller. This is a smaller but annoying change. Like this change, 2,000 registers, this change is 300 registers, and then the change in another number or something here. So then the changes are back to being small. This is the most traumatic one. The big change on the 3D side though was between the VibaxX and the 6XX. Notice I've drawn the 690 back here because it's a transition part. It's a display controller from the VibaxX, and it's the acceleration hardware and 3D. I didn't even draw a block between the CoreXX and VibaxX. There are changes there, but they're relatively minor. So fundamentally, 3D Engine doesn't change all that much on the VibaxX. The 6XX is where it changes. It's all unified shader at that point on. The programming model does not have a question. Yeah, and I need time to release the 3D documentation for it to make things... Yeah, so two parts to the answer. We have an old programming guide for DDK. Oh, yeah. Sorry. The question was 3D documentation for the 2XX. So the answer there is... I'll do it in two parts. One is we had programming guides and DDK information which covered a good part of the 2XX functionality but did not cover the programmable vertex shader, for example. So the first thing I'm going to do is really return and find an editable copy of the document. It was a lot of years ago. For example, this machine has two pieces and it's not supported by the official source driver anymore. So I can't get 3D in this machine. Yeah. So we're going to provide more information. Alex is working for us. He's got no access into all the hardware databases. But once you get back before the 3XX, it becomes harder to find. So the second answer is for the documentation we already have which is everything except the programmable vertex shader part we're going to re-release that for sure. I'm just hoping that I don't have to take things over and put it in the scanner. I'm not sure whether to... My guess is actually that the documentation we're releasing for the 3XX will probably be enough to figure out the 2XX programmable vertex shaders. There was really a lot here. The 2XX actually had fixed function and kind of the first generation programmable vertex shaders. 3XX we took away the fixed function and beefed up the programmable part. So I'm not sure... But how we said that the open source driver was only used fixed function today. So probably the short answer is yes. It's going to depend a bit on how quickly we can find it as a copy of the document. So I'm not going to guess on time, but it should be relatively safe. Oh, I got the OCR. Sorry? Oh, I thought you had the OCR. Oh, yeah. Someone's got a OCR. And it always ends up being me. So for the worst case I can say if you want to, we've got an email address, gpu, driver, dev, support, whatever. If you just want to fire off an email with any questions on that, Alex has got access to all the information we've got. And then basically for the older parts, we're looking more at answering questions and fixing things, whereas for the newer parts going forward, really 3XX and off, is we're trying to say here's the documentation. Because there's one of the problems we had with the documentation that we have here. It's sort of a joke internally, but basically what it looks like is it took about 20 people to write the documentation of about 7 people read it. And then again, those don't seem like the right numbers. Sorry. Okay, yes? Yeah. So basically, okay, it's always a challenge understanding our marketing numbers. But furthermore, this is X1XX, and this is X2XX. And some trees. So basically, as long as you can get back, it can be good. Tell you what. If you can figure out what four it is, you know, the 2XX or 3XX or 4XX, the hardware is the same. Fundamentally, we enable more functionality. We fuse step on and off. We test and sample for different, you know, speed versus power kind of things. But fundamentally, the program is pretty much the same way. It's just a different problem. Pick a mailing list of choice and ask, what is this? And if nobody else answers, Alex will. Okay, so... Okay, so basically these three engine changes between 5XX and 6XX, and that's what it keeps evolving, but you don't get the big branch of changes for a while. Video, so... The backend part of video processing, or you mentioned, it's all done on the shades nowadays, anyways, basically the XB functionality. Motion comp also uses the shaders. There's dedicated hardware in there for ADCT that's been around for a while. It's been around like, just before the radion. So it changes here, in the sense that the way you program it, the way you synchronize it, is different to pick up new video formats and stuff, and it persists all the way to the end of the 6XX line. 780 is the first chip that does not have the legacy ADCT. It's looking like we should be able to open up the information on this. Motion comp is really a 3D engine with some specialized, you know, put it in this mode rather than that mode, because MPEG has some different, you know, everything from grounding, those kind of things. So fundamentally, render processing, motion comp, they're all 3D anyways, the ADCT and the, the no ones for HF264, DC1, they're handled in a UVD. We're not sure about opening up the UVD block yet. So we're going to try it, but right now we don't have a way to do that. Okay. 5XX 3D update title is Acceleration, and return to make it clear it's not a total programming guide, it's an acceleration one. It's about half how to use and about half register specs, and then how to use this car it is, you know, vertex formats and how all the routing and the sizzling and all that work. Private shader, implementation, the hardware is totally different. So from a performance standpoint, things that make you go fast, stuff like that, they're all new on the 5XX. And the primary thing is the sequencer, the amount of threading it can handle, that's all different. Programming model is almost exactly the same. So main change is the shader, the actual shader, off-codes for the private shader, they're loaded differently. One thing I found very confusing early on is we talked about universal shaders, which come in about the R300, where some texture processing and pixel processing is combined. Those are universal shaders, sometimes it's some type of correctivity unified shaders, something like that. So anyways, it's universal shaders for 5XX in the back, and it's unified shaders for 6XX and up, and they both abbreviate the same way, so beware. The way we map from GPU address spaces to post address spaces, so, you know, HGP Guard, PCI Guard, that kind of thing, that's different on the 5XX, that's the one thing with the T-Core structure panel, we need to push out separate links. There's a bunch of virtual machine context solution type stuff in some of the chips, basically using it essentially as, you know, maybe production vehicles from the future, depending on how the standards work out. We're not using a lot of it today, and we're not proposing to support you using it either. We don't do anything to make sure it works in a production chip, so I strongly recommend you not very use it. So the only part that we're really using today is the, essentially like the PCI Guard type functionality. So it's called Pro process page table in 5XX, it's got a different name, but does much the same thing in 6XX. And that's the one thing we haven't got programming information out to you yet. It's in the T-Core stuff, and we'll take out some of it real quick. Anybody got time to check? Three. Okay, so 6XX. We focused a lot on the 5XX documentation to get it out the door. So we haven't gone so far on the 6XX side. The main point there is that all the details are different, but fundamentally the programming model hasn't changed. It's still vertex buffers, indirect buffers, index buffers, all that stuff. The main point is that the blocks you twitch to have those polygons processed in a certain way are in different places. Most of the functions translate one to one, but you get this register instead of that register. Fundamental change, which is one of the vertex assembler processor, is, this included the vertex shader part is replaced with the vertex grouper and tessellator, which does pretty much the same thing, but instead of doing the vertex shading inside, it lines all the stuff up and feeds it up into the unified shader block. There's a bunch of new blocks to recirculate, because typically using a geometry shader as well, you've got three passes through the shader block even before you get into multi-pass rendering. So, there's a bunch of new blocks through that, there's little storage areas, you know, sort of rather than just having a pipe where you've got vertex shaders and then pixel shaders, you've got two unified shaders and then a bunch of storage things at the end, so those two once feeds around again, might feed around a third time and then goes out into the back end into beginning memory. And hardware changes are pretty significant, partly for more color processing capability, partly to make it go faster, partly for DX10. So, one of the things that we're probably going to do is try and pick out, this is the stuff we need today, you know, for OpenGL and type driver worthy, and we might do that, we might basically release the documentation in two stages. And what it's really going to be is the second stage of what you need to write the DX10 driver. I don't know if that's high on anybody's list, anyone? No? And the memory management changes again. Okay, power management. Most requested things, power management. Part of the problem from what I can see is that our customers implement very nice, clever little power, little fan temperature monitoring things that we provide under Windows. So, under Linux, your fan either runs wide open or it doesn't run at all. Neither is optimal. So, the fan controllers, if we're one of the process products, there's a few standard chips, but there's like a million different ways to hook them up. And so, we're trying to dig that out. We put a fan controller in, I think starting at 630. We're trying to get people to use that fan controller rather than something grafted on the outside. Yeah, thank you. We should compare those. I don't think we're totally winning yet. So, the most common question I get is, can you tell me how company X, Y, Z designed this product? So, the answer there is basically no.