Nouveau - On-going work, demos and research
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Peres, Martin
Nouveau is an open-source driver for NVIDIA GPUs developed through reverse engineering by the community. This talk will discuss the achievements of the driver, what happened these last 2 years, what we are working on and what may change in the future. Special emphasis will be put on power management as it is the most-lacking feature in our driver. Some demos and Q&A will close the talk.
 So today we'll be talking about Nouveau and a recap of the work that has been done, what we are doing and what we are planning on doing. So today on the stage, I'm Martin Perez, this is Emile Velikov and Martin Akashenliki. We were supposed to have Martin Lancoste, so three Martins, but yeah, he's not here. So, okay. So the reason for this talk is last time we discussed about the updates on Nouveau was that first time 2012. We've done another one at XDC, but it's not first time, so let's do it here too. And of course there were many improvements since then, so yeah. So Kepler, a new family of cards. So after Fermi, NVIDIA released Kepler. Kepler is very power efficient and faster. It was released in March 2012 and we actually got mod setting support on the same day. So the reason why we managed to do that is because OEM actually sent a card to Ben's Cags in advance. So we had the card for 15 days to prepare for the same day release. And then there was some unreleased 3D support, what happened a few days after. But as we were in the middle of rewriting the MISA driver, it was the new LibDRM. Then it took about a month in order for it to be released and accessible to everyone. So the rest of the talk is divided in kernel, user space, and then the tools we develop. So we'll talk about the kernel. So big update, Nouveau left staging. So it's now supposed to be stable. We try to. We also rewrote the internal architecture of the driver. It used to be Kepler code, not Kepler but Fermi code, used to call some code written for the TNT2. So we had problems sometimes with regression. By fixing a chipset, we would just threshold the others. So the new core architecture is now separated in per chipset. It's easier to know what are the dependencies. And it helps with the regressions or it should help. It's object-oriented. So it really helps for keeping track of who is using the engines. And this is going to be very interesting for power management. For instance, cutting the power of the engines that are not used. It's going to stop. It used to be impossible. Okay. Next thing, Optimus and Prime supports. So Optimus is the technology developed by NVIDIA. They use an Intel GPU and then an NVIDIA card. So usually it's the Intel GPU doing the old, the display and the 2D acceleration and 3D2. Whenever you want to launch a game to get performance, then you use the NVIDIA driver. So you get a low power consumption when you're doing browsing and all that. And when you want a game, then you have the performance that is available without the power consumption hit. So the work for that has been added to Linux 3.9 by Dave Early. And we are still waiting on the synchronization between the drivers. So it means that if you use one driver to do the rendering and one driver to do the blading or sending stuff to the screen, then you'll see some tearing because the two drivers are not synchronized. It's not going to tear, but it's going to be choppy. Yeah. So if you want to have more information, you can have a look at the wiki page on Optimus. So power management. So power management should be working on almost every card now. So it means temperature monitoring. There are so many ways of, there used to be so many ways to get the temperature on the card. It's crazy. Especially on the G4 7 cards, we're not even sure that it actually works well. We had a bug, someone complaining about the temperature being 3,000 degrees. So obviously it's not working well on every card. Yeah. No, it's not possible. So on G4 8 and later, it works for every card, except the one with I2C only temperature probes. So the reasons why we cannot get this temperature in the driver is because of the HWM architecture, which is used to export a program. That's the driver for the temperature probe, but it only exposes the temperature to the user space. So the kernel space cannot use the information. We've been trying to change that for a while. When I say a while, it's several years. And so far, yeah, nothing has changed. We even proposed a lot of code, but yeah. Fan management, static fan management for Tesla, G4 8 to Fermi, so G4 400. It was added in Linux 3.7 and it worked. And there was a couple glitches, but it was fixed shortly afterwards. Yeah, there were some glitches. It was during the AC period. So hopefully no one saw that, no end users. We added experimental fan management in 3.9 and it's now enabled by default on 3.13, but it doesn't work on all Keplers. So yeah, that's problematic. They added a new way to drive a fan and they've been very inventive in ways of driving the fan or reading the temperature. And there is a new way that we don't support yet and we need to understand how it works. But I've been bashing my head on my keyboard for a while to understand that. So if you have any problem with that, terminal management, fan management, you can contact me. Yeah. So let's continue on power management. Rick Clarking, you've been hearing about this for a while on every foreign, foreign next article about Nuvo. Michael complains about lack of proper reclocking. So for those who don't know what this is, it's changing the frequency of the engines of the graphic cards. It means changing the voltage to, changing the memory timings, changing everything. So this is very difficult to do, especially when you don't have a programming guide. So we do that by reverse engineering. It should provide a lot of performance when you need it and you can lower the clock when you don't need it so you can save power. By default, on Fermi, the clock are at the lowest, so basically a tenth of what you would get for the high performance mode. So you get a tenth of performance. Yeah. So quite a performance here. Then power and clock gating are ways to lower the power consumption without heating or slowing down the engine. It's very good, but we don't have support for that yet. It's mostly done by the hardware, but we need to set up all the registers for that and we don't really know the list of registers and what we should put. It seems like NVIDIA is just putting numbers and there's no logic in it. So we'll try to use that and if users complain too much, then it means that it doesn't work because that's the only way we can test. So yeah, it should be released soon for Fermi and Kepler because of some code that has been released for the Tigrayer K1. So they basically, we now have a list of all the registers and the value we should put. We are going to check if it's what needs to be put for the desktop cards and if it works then it's good. But at least we have a register list, which is good because I found a third of this list on the third. And I was wondering why I didn't have the same power consumption. Okay, performance and power monitoring. So the big thing is that some Kepler actually have a power sensor now. So they used to have an internal hardware model of the card and with some... So basically it would check what part of the engine is active and then if you assign a weight on that and you integrate and you do all this stuff in hardware, power consumption reading and you get it about 500,000 times per second, which is quite nice for power cupping, but we won't talk about that. We also, we should soon have a rough engine usage indication. So for memory, graph is the graphic engine and video... Oh yeah, the video decoding and engines. And that's going to be used for dynamic reclocking. So when we need performance, we can increase the clocks. Okay, so we'll move to the user space. Performance counters. It's a bit like the engine usage indication, but it's much more accurate. So we added support for MP, so multi-processor counters. Let's put it this way. It's GPGPU. Well, we exposed that for GPGPU. Right now it's only exposed through the Gallium HUD, so it's basically graphs displayed on top of applications. So the Kepler support was added by Christophe Bermelie, our main Gallium developer. And the Fermi support was added by Samuel Pitoise. He was my GSoc student this year. He also fixed the Kepler support for the other cards that Gallium didn't have. So work in progress. We still have to reverse engineer all the graphics-related signals. Unfortunately, we need Windows 7 for that. Yes, yeah, W7. So on Windows 7, we had to port our tools to Windows 7 so as we can do the reverse engineering. So it takes a lot of time, but it's still working on it, so this is good. And then the performance monitoring for PDM. Yeah, that was the usage indicator that I said should arrive shortly. Okay, and I don't know why I didn't export the kernels. Maybe it's just a copy paste error. Okay, so this was supposed to be presented by Martin, but since it's not here, I'm keeping the mic. So I talked about LibJRM2, the LibJRM rewrite, when I talked about the Kepler support that took some time to actually reach end users. So the first thing we needed was the new LibJRM was to expose the graphic drivers address in the virtual memory. So this is very important for GPGPU. Without that, we couldn't do GPGPU. So now we can. We also support multiple threads, so multiple application per hardware context on the card, because Nuvo uses hardware context and I've been doing so for a while. So it means that when it crashes, then the whole desktop crashes, basically. But we gained a lot of performance out of it. So, yeah, and security too. So the relocation mechanism has been reworked. I didn't work on that and I couldn't get information on what it meant. People forgot already. A lot of users actually reported the no space error. So it means that TTM couldn't find a space to put the buffer. With this new API, it reduces that a lot. So now I don't think we have bug reports on that anymore. It's possibly one or two, but it's bearable cards. Yeah, when you have no memory, of course, you cannot have a very big... Basically when people want to drive... Basically when people want to drive something like 10, 20p, roughly a resolution, or 10, 2, it just doesn't work. It doesn't have enough memory. But yeah, that's to be expected and of course, we can't do anything about this. Sorry about the noise. So then, since we rewrote LIT DRM, we needed to rewrite the misadrivers. So it was a good thing actually because the NVFX driver got rewritten. This was a mess. It's the driver for G4, 6 and 7 and 5. So 5, 6 and 7, it used to be... It used to run open arena and that's about it. So Ben's kegs worked a lot on that and he changed the name for NV30 and it didn't fit the... Okay, so before that it was called NV30, then NVFX and then back to NV30. I didn't know that. I'm too new. So yeah, now it works much better. It's not perfect, but it works much better. And the naming scheme is better because we have the NV50 and C0 drivers. So NV30 just fits nicely compared to NVFX. Okay, that's it. Video decoding was a big new feature added by Martin Langhorst. He's not here, fortunately. So he added the support for Fermi and Kepler. I mean, it's the same thing, so basically the same thing. So it didn't have a lot to do. But it used to rely on... Well, it relies a lot on firmware's. So video decoding is done on the hardware. So you need to send the codecs to the card so as it can decode and push everything on the screen. So these firmware's are proprietary. We use the Nvidia firmware's. And we use to ask user to extract these firmware's from MMIO Trace. And MMIO Trace is looking what is going on on the PCI Express bus or what the driver is doing. So every interaction, as with the card, we can log it. And from that, we can recreate the firmware's. So needless to say, it's a pain to do that for end users. But the reasons why we didn't ship the firmware's was because it's... Well, we are not allowed to register or distribute them, so legal problems. So to overcome that, Ilya Mirkin actually wrote a script to extract the firmware's from the proprietary driver. So you just need to download it. No need to install it. It will extract the firmware's from the... What we call the blob. And then you can just use the firmware's. So it's very easy. On Arch Linux, we have a package for that. It's very simple. It takes more time of downloading and then you have the firmware's. So it's very simple. I don't know for other distros. Gento has one in the pipes. Okay. Yeah, I don't know for Debian and Ubuntu how they are going to do that or Fedora. But, I mean, yeah. We did our best. And as we don't have legal console and all that. Or maybe we can just ask NVIDIA now if they want to allow us to register or distribute the firmware's. Who knows. So Ilya helped on that, on the script. Where is it? No. But he also supported the support for NV50, so GeForce 8. So now we have video decoding support from GeForce 8 to the latest cards. So that's full support for H264, MPEG12 and another one, VC1. Basically every hardware that supports full acceleration has it. I believe the NV84 to NV96 which has partial support for... It's there, PMPEG. Yeah, with PMPEG you can get MPEG1 and 2 acceleration and it's for NV42 and NV96. So GeForce 7 basically. So GeForce 7 can have acceleration. But it's crap. MPEG2 acceleration is not useful at all. So if you want more information, you can visit the Wiki page, video acceleration. It's very up to date. It will tell you what driver you need, so what you need in the kernel side, MESA and the firmware, of course, and what the hardware actually supports. Okay, good. OpenGL, a few days ago. I don't know if you saw the news, but we reached OpenGL 3.3 for NV50 and in the C0. So basically everything after GeForce 8. It's going to be in MESA 10.1. So history a bit of our support. Basically we added OpenGL 3 support in MESA 8 so whenever the Intel driver got it to work. And we got OpenGL 3.1 in MESA 9 apparently too. So we can't remember if it was 9 or 9.1. So yeah, we don't remember that. But basically we've been having a good track following the releases of Intel. But only for NVC0. So this is very interesting because this one has NV50 and C0 at the same time. Usually GeForce 8, no one cares about it. Yeah, it's getting old. So we still have limited support for GK. So basically the two latest Kepler cards. And yeah, I can't remember why. You mean the instruction set maybe? Yeah, I believe there are some subtle changes in schedule and a few others which hasn't been dealt with. Oh yeah, we can use this mic. Forgot about it. So as I was saying, I believe there is a couple changes in the ISE. Oh, there's a new ISE which apparently we haven't had a reverse engineer support. So that's why it doesn't work. But I believe the primitives, it should work. Just the more complex stuff. Shaders. Yeah, that might take a while. Basically you have your compositing environment and that's it. Okay, one last thing. So the good thing with Gallium, the Gallium infrastructure in Nuvo, is that there is a correlation between the drivers and what we call the state trackers. So this architecture allows us to create a new, for instance, support for OpenGL and then all the drivers can add support for that and they don't need to rewrite everything themselves. So there's been a new state tracker, a DRX3D for DRX9 state tracker. It was started by Joachim Sinholt. I don't know this guy, but good. Thank you. And it was completed by Christopher Bumela, our main developer of Mesa. So we managed to run Skyrim, Civilization 5 and Starcraft 2 and we can get up to twice the FPS than Wine's DRX3D implementation. So when you do DRX3D in the driver, it's way faster. Good. Yeah, apparently they got better. But I mean Wine, but I don't know. So the announcement is here and if you want to compile it, well, you have the link. The readme should be interesting. I've never tried it so. So now I hand the mic to... Just a brief one on the compiling. If you want to compile the branch, it's rather old. So it should be straightforward to rebase. But if anyone is struggling, most likely, I'll put a note at the end, there was a guy that actually rebased it and he did sort out a couple of small glitches along the way. So you'll see that one shortly. So I wanted to talk about the tools for the new driver. I'm not developing the real driver, I'm just a tool developer. We have a set of tools like registered database, MIO trace decoder, assemblers and these assemblers for all the ISAs that NVIDIA uses. NVIDIA BIOS decoder, something else. And yes, I am taking care of the other package of tools, the NVTools that contain some of that. There has been a lot of work on it recently. First and foremost, we moved to a new repository. The NVTools was previously hosted on... on GitHub, on a path scale organization because, well, they originally did a lot of work on it. But it caused problems because not everybody had push access to their repo. We had to use some people for the repo and had another repo at the source forge. I had another private one. So we recently cleaned that up. We have now a new repository on GitHub where every developer has admin rights. So it's much better that way. Now what are we doing in NVTools? First, we're making documentation for the NGPUs. The project started two years ago, I think. We just plaintexted documentation of some bits of card that we know really well and might be interesting for new programmers. It started with the Falcon ISA docs for one of the microcontrollers that drive the card. We're slowly working to make it cover more of the card. We're working quite well but slow. But the plaintext format turned out to be... It was nice to write but not nice to read. So we recently moved to a new documentation system based on... The Sphinx documentation system, the same one that Python docs use. With Sphinx, you still write the documentation in plaintext but with a few special markup features. Sphinx generates a nice cross-referenced HTML from it. So you can easily browse it from your web browser. You can just go to that URL and have a look. And a new feature that Sphinx allows us to do is embedding register references right in the documentation. One of the features of NVTools has always been the register database. It's written in XML and it contains a list of every register we know on NVDA GPUs. It's used for several purposes. It's used to generate headers for the other drivers with the register addresses and values for them. It's used to decode NMIO traces but our tool is used... It can also be used for send-in-a-long lookup purposes. The problem with that is that basically every register is mentioned twice in the NVTools repo. Once in the XML database and once in the documentation. So we're now adding support for new special markup to Sphinx so that we can just describe the register in the plaintext documentation and it's going to generate the XML out of that. Another tool that was made for Nouveau is the Falcon C compiler. Falcon is a kind of microprocessor embedded in the NVDA GPU. It's used for many purposes including video decoding, including graphics context switching so we can run more than one 3D application at once. It's used for power image band. So Sphinx Pekato made a C compiler for that ISA so that we can write the microcode for Nouveau in C instead of doing it in assembly like now. It's been worked on the assembly and disassembly of this. So we just needed a compiler for that. Right now it works only for the Pgraph firmware, so only the context switching firmware, but with a bit of work it should be easily acceptable to support PDMons, which is the power management engine. And if you want to read about it, here are some links. And the most recent tool, the compiler, basically to learn how some microprocessor on the NVDA GPUs work, we have to look at the firmware for that. Normally we don't like to the compiler things because it's basically too hard. It's a lot of work to the compiler something and you can spend weeks just tracing some functions, what calls what, what's the type of the structure, and it's really slow to figure out how the hardware works by the compilation. But normally we use MIO traces with just using on the communication between the driver and the card, on the PCI Express bus, but when a piece of hardware is controlled by the microcontroller right on the card, you can just listen to what it's doing because there's no easy access to it. So we have to just take the fervor and compile them to know what's going on. The process has been done by hand for a long time, but that's really inefficient. So my master's thesis is the compiler for that Falcon ISA. It's meant to take care of all the repetitive issues in the compiling microcode. Right now it works, it's quite well for some pieces of microcode. We had support the full Falcon ISA, but it's enough to read the pgraph microcode. It's written in quite an architecture in an abandoned way, so it can be extended to support any ISA. Right now it has support for most of Falcon and VP2 macro ISA that's used... It's one of many controllers used in video decoding. I just picked it because it was the easiest ISA to get going. And, well, the results are quite nice on the ISAs. You give it a binary, give it some hints where to start decoding, and it spits out basically pseudo-code that has normal control structures, it has variables, so it's much easier to read than the assembly code that we were used to. It's still not public, it will be released soon when my thesis work is done. Right. But I hope you can hear me. As I said before, my name is Emil, and I'm going to talk a little bit on the community side. So I'm not sure how many of you are using Nuvo, how many of you are actually active or not. I'm trying to be active, but everyone has other obligations. So, firstly, I'm going to have a brief about the bugzilla cleaning. So if you are aware, Nuvo used to be a user mode settings driver, which meant that everything was done in the DDX, which wasn't that great. So the bottom line is since we moved into the kernel, Nuvo has been a KMS-only driver. And if you look at the bugzilla, it had dozens and dozens of bugs about the EMS driver, and quite a lot of those weren't updated for years. So Ilya Merkin did a remarkable job, which possibly some people hate him for, because, oh, he closed my bug, put so much effort into it five years ago, and then I stopped just getting bother updating it. So what he did was he cleaned up a lot of the bugs. He basically did a mass closure of bugs, which hasn't been updated for over the last two years, three years. The bugs went down significantly, as you can see. But there has been quite a few bugs I managed to get solved. People actually said, oh, yes, I am still having the problem. And with recent changes in kernel and everything, we can get a bit more information of, for example, where it's crashing, what kind of a problem it is. So, yes, as I said, there have been quite a few fixes on that. Next thing is, I'm not sure how many of you are familiar. Free Desktop has moved their wiki system. And actually, it's a good thing, because there was more than enough spam. And while doing that, there has been more than dozens of obsolete wiki articles, and some were not that out of date. So what Ilya and Martin over there did was basically they nuked most of the obsolete ones, and they rewrote the cover pages, the bugzilla page. And that one worked out very nicely at the moment, as you just go to the wiki, you just get a nice big picture, and you see, OK, what do I look for? Click on bugs, and we make sure we update the so-called latest version of the software, because as you can see, there aren't that many of us. It's not that easy to always keep on going and backporting, for example, for MISA 9.0, where basically there's two people actually doing some work on it. So we always recommend you try that latest software. So, as I said, we cleaned up a lot of the craft. There's still some in there, I believe, but if anyone's keen on doing it, you're not then welcome to just walk into IRC, say, oh, I noticed this page, I want to help. Great. They will need rights for that. But that's the problem with the new wiki system. You need an account, a free desktop account. So, yeah, so you can... You need to ask for the rights. It's not a free desktop account as in a SSH account, but still. Yeah, that's what I said. Basically, come to the IRC channel and tell us, okay, and basically we'll work something out. I'm not sure what the procedure at the moment is, but it should be almost straightforward to have a setup and working if you really want to help. Please do. Yes, please do, because there is a lot of stuff in there. And not just wiki, there's a lot of stuff almost everywhere. Well, you can get free wiki if you haven't... If you have an SSA account, you can get free wiki if using the password generator for the wiki. So, yeah. Okay. That's pretty silly. I'm not doing any of that administration, so I'm not commenting. You just avoided that. I'm not doing administration. Okay, so you definitely have heard some of these stuff. So, at XDC 2013, they released some disclosure documentation, which meant great for us. Additionally, there was obviously an email from NVIDIA, which clearly stated, we want to improve the Out-of-Box experience for NVIDIA users, which is, again, great. I believe we had one significant piece of documentation, which did cover a couple of buggy areas in NVIDIA, possibly there's still a couple more areas which NVIDIA needs to extend because of the variety of various connectors, especially docking versus non-docking setups, etc. This is what the DCB-related VBO stables means, display connector blocks, if I'm not mistaken. Additionally, one of the new guys noticed that MSI weren't working that greatly. So NVIDIA were kind enough to provide us with some information as to which specific chipsets needed to get what, I should say, methods to avoid any issues or having at that point. And additionally, a very, very nice help in terms of video recording, because William Merkin, as he was working, I believe, on the... VP2 or VP3? Yeah, VP2 and VP3, it was at the first few seconds of rendering and recording, the recording was great, just it was crashing in two seconds. And yeah, so great, that one got fixed, perfect, like more than half it's, but I don't have such a card, at least you can use it. What's next? Oh yes, so we're talking about TigraLand. It's good because we did not have a few registers, as Martin mentioned earlier, which for me doesn't ring a bell because I haven't looked it in... Yeah, at least for power management, they have... Many of the registers are the same, the Tigra K1 is based on a Kepler card, yeah, for graphics, but still some engines are very similar or exactly the same, we don't know yet, mostly a mix of both. And then, so we have the register dumps, so it means the addresses, their name, so the name may be cryptic, but usually it gives you an idea of what this is, and then the values that should be stored in them, the default value, or what means every part of the bit field, so it's very, very nice, especially for stuff that you cannot really reverse engineer easily, such as the hardware model for the power consumption of the card. I wouldn't know that at one point this is just for the graphic 2D engine, and this is for the 3D engine and all part of it, so now we can have a proper documentation on that, which is nice. Yeah. Okay. And additionally, I believe, was yesterday morning, I thought I was still sleeping when I saw another C-patch set, which is great. The belief provides just some very small architectural work on Nuvo, such as that provides support for non-PCI devices. It basically adds, I believe, a very basic support for the Tegra K1 device, and if I'm not mistaken, so don't quote me on that, it doesn't provide any mode settings, so... It should work. There is no display engine on the GPU. Okay, so... It's just rendering. Yeah, so... So yeah, basically now you can use Nuvo to work as a DRM driver for the Tegra K1. They won't work on the user space, so 2D and 3D acceleration, but if it's really based on Kepler, it should pretty much work out of the box with our drivers. So we'll see, because we don't have the hard one yet. But this would be something very interesting, right? Yeah, definitely. And as I said earlier, if genuinely, if anyone's willing to help, or if it's got a few moments, or if, for example, if you're lurking in Nuvo channel and you see someone coming up with a trivia question, just please help out, because there aren't that many of us. I said it for like four times now, and it would be great if people just come forward and say, oh, for example, I'm very good at programming and C, or for example, I love writing documentation. For example, he can help out Martin with, hey, people like... We are really looking to find someone interested in compilers, because we suck at it right now. Oh, yes. And yeah, we need people for that. And yeah, please. But in general, whoever's willing to help, just come forward either in the IRC channel, or send an email of either one of us. We rather straightforward find, if not, just give us a shout, and we'll get you sorted. Maybe we can give our nicknames on IRC. Oh, yeah, mine is funny. So is ZexAXO, is NWK, I'm NuProof, and MLMCost. Yes. Yeah. Basically, that's it. Thank you very much. And if you have any questions? Thank you. Thank you. Thank you. Thank you. Thank you. Questions, questions. Okay. I'll just take a quick question on your side. Wait a sec. Sorry, I just turned up. Who's working on it on the NVIDIA side? All of them. You're on the side? No, no. Who's working on NVIDIA working on it? I don't know. I think you misunderstood. NVIDIA now is starting working and improving NuVo. Yeah. So there are NVIDIA engineers. We don't know them yet. Oh, you don't know them yet? Okay. That's my question. Thank you. I can't believe we've been clear enough. No. Probably. This documentation that they released in 2013, how much would you say that it covers? I mean, that one percent of the VBios? No, they explained the VBios, the video BIOS, which basically describes how the hardware is laid out and if it has support for like, does it have an external display connector or not? Or is it a special media box or something like that? And it's really helpful because a lot of those configurations we wouldn't see in the wild. So we can add support for something we don't necessarily have ourselves. Anybody else? Yeah. And does the documentation on the BIOS also cover old hardware or only weather-recent hardware? Basically, when they release new BIOS, they add support for, they add support next to the old stuff they have. So they explain new stuff, and in that we can work out the old stuff as well in some cases. Like some connectors we are already using old cars, and we saw them but we didn't know where they were necessarily. So now we know where they are and we can add support for the old stuff as well. Okay. So when I run the in the war driver, is there a chance that my graphics card may break or are there, at least in theory, enough safeguards? No, it could self-destroy. But yeah, I never managed to, and I've been heating my cards with, oh, what's the word for that? Herdryer. In order for it to reach 130 degrees to test some, well, I didn't know how it worked at the time, but there is a dedicated part of the engine working on thermal management, and I knew there were thresholds and all that for temperature, and I wanted to check in the Vibios where was the temperature written, and in the hardware, so I had to do stuff like that and test everything, and yes, I reached even more than that. And the card never, I mean, it still works perfectly. So yeah, and it's been stupid enough to do that on a Fermi, and it's still working. I mean, running games at 130 degrees, it does that. It was just desktop compositing, but still. What? Okay, weird. Yeah, so it could in theory happen, but it's unlikely. I've been torturing cards for a lot of diamonds, none of them broke, so... Basically, I believe Martin here has second to envy the biggest collection of their cards. If you go to a page, you're going to be just shocked by the vast amount. I think you're missing 10 overall, or a little bit short of that. Something like that. 50, I think. I've run long loops that wrote random values to all their registers on cards, and none of them broke. So it seems rather hard to destroy a card in software. Well, in some cases I did manage to break it, but then if I turn the power off, and then wait for like 30 seconds for it to finally stop getting any power, then it would work again. So, yeah, it's very hard, but if it breaks, you get to keep both pieces. Anybody else? Okay, thanks a lot, guys.
 So today we'll be talking about Nouveau and a recap of the work that has been done, what we are doing and what we are planning on doing.  So today on the stage, I'm Martin Perez, this is Emile Velikov and Martin Akashenliki.  We were supposed to have Martin Lancoste, so three Martins, but yeah, he's not here.  So, okay.  So the reason for this talk is last time we discussed about the updates on Nouveau was that first time 2012.  We've done another one at XDC, but it's not first time, so let's do it here too.  And of course there were many improvements since then, so yeah.  So Kepler, a new family of cards.  So after Fermi, NVIDIA released Kepler. Kepler is very power efficient and faster.  It was released in March 2012 and we actually got mod setting support on the same day.  So the reason why we managed to do that is because OEM actually sent a card to Ben's Cags in advance.  So we had the card for 15 days to prepare for the same day release.  And then there was some unreleased 3D support, what happened a few days after.  But as we were in the middle of rewriting the MISA driver, it was the new LibDRM.  Then it took about a month in order for it to be released and accessible to everyone.  So the rest of the talk is divided in kernel, user space, and then the tools we develop.  So we'll talk about the kernel.  So big update, Nouveau left staging. So it's now supposed to be stable.  We try to.  We also rewrote the internal architecture of the driver.  It used to be Kepler code, not Kepler but Fermi code, used to call some code written for the TNT2.  So we had problems sometimes with regression.  By fixing a chipset, we would just threshold the others.  So the new core architecture is now separated in per chipset.  It's easier to know what are the dependencies.  And it helps with the regressions or it should help.  It's object-oriented.  So it really helps for keeping track of who is using the engines.  And this is going to be very interesting for power management.  For instance, cutting the power of the engines that are not used.  It's going to stop. It used to be impossible.  Okay.  Next thing, Optimus and Prime supports.  So Optimus is the technology developed by NVIDIA.  They use an Intel GPU and then an NVIDIA card.  So usually it's the Intel GPU doing the old, the display and the 2D acceleration and 3D2.  Whenever you want to launch a game to get performance, then you use the NVIDIA driver.  So you get a low power consumption when you're doing browsing and all that.  And when you want a game, then you have the performance that is available without the power consumption hit.  So the work for that has been added to Linux 3.9 by Dave Early.  And we are still waiting on the synchronization between the drivers.  So it means that if you use one driver to do the rendering and one driver to do the blading or sending stuff to the screen,  then you'll see some tearing because the two drivers are not synchronized.  It's not going to tear, but it's going to be choppy.  Yeah.  So if you want to have more information, you can have a look at the wiki page on Optimus.  So power management.  So power management should be working on almost every card now.  So it means temperature monitoring.  There are so many ways of, there used to be so many ways to get the temperature on the card.  It's crazy.  Especially on the G4 7 cards, we're not even sure that it actually works well.  We had a bug, someone complaining about the temperature being 3,000 degrees.  So obviously it's not working well on every card.  Yeah. No, it's not possible.  So on G4 8 and later, it works for every card, except the one with I2C only temperature probes.  So the reasons why we cannot get this temperature in the driver is because of the HWM architecture,  which is used to export a program.  That's the driver for the temperature probe, but it only exposes the temperature to the user space.  So the kernel space cannot use the information.  We've been trying to change that for a while.  When I say a while, it's several years.  And so far, yeah, nothing has changed.  We even proposed a lot of code, but yeah.  Fan management, static fan management for Tesla, G4 8 to Fermi, so G4 400.  It was added in Linux 3.7 and it worked.  And there was a couple glitches, but it was fixed shortly afterwards.  Yeah, there were some glitches.  It was during the AC period.  So hopefully no one saw that, no end users.  We added experimental fan management in 3.9 and it's now enabled by default on 3.13,  but it doesn't work on all Keplers.  So yeah, that's problematic.  They added a new way to drive a fan and they've been very inventive in ways of driving the fan or reading the temperature.  And there is a new way that we don't support yet and we need to understand how it works.  But I've been bashing my head on my keyboard for a while to understand that.  So if you have any problem with that, terminal management, fan management, you can contact me.  Yeah.  So let's continue on power management.  Rick Clarking, you've been hearing about this for a while on every foreign, foreign next article about Nuvo.  Michael complains about lack of proper reclocking.  So for those who don't know what this is, it's changing the frequency of the engines of the graphic cards.  It means changing the voltage to, changing the memory timings, changing everything.  So this is very difficult to do, especially when you don't have a programming guide.  So we do that by reverse engineering.  It should provide a lot of performance when you need it and you can lower the clock when you don't need it so you can save power.  By default, on Fermi, the clock are at the lowest, so basically a tenth of what you would get for the high performance mode.  So you get a tenth of performance.  Yeah. So quite a performance here.  Then power and clock gating are ways to lower the power consumption without heating or slowing down the engine.  It's very good, but we don't have support for that yet.  It's mostly done by the hardware, but we need to set up all the registers for that and we don't really know the list of registers and what we should put.  It seems like NVIDIA is just putting numbers and there's no logic in it.  So we'll try to use that and if users complain too much, then it means that it doesn't work because that's the only way we can test.  So yeah, it should be released soon for Fermi and Kepler because of some code that has been released for the Tigrayer K1.  So they basically, we now have a list of all the registers and the value we should put.  We are going to check if it's what needs to be put for the desktop cards and if it works then it's good.  But at least we have a register list, which is good because I found a third of this list on the third.  And I was wondering why I didn't have the same power consumption.  Okay, performance and power monitoring.  So the big thing is that some Kepler actually have a power sensor now.  So they used to have an internal hardware model of the card and with some...  So basically it would check what part of the engine is active and then if you assign a weight on that and you integrate and you do all this stuff in hardware,  power consumption reading and you get it about 500,000 times per second, which is quite nice for power cupping, but we won't talk about that.  We also, we should soon have a rough engine usage indication.  So for memory, graph is the graphic engine and video...  Oh yeah, the video decoding and engines.  And that's going to be used for dynamic reclocking.  So when we need performance, we can increase the clocks.  Okay, so we'll move to the user space.  Performance counters.  It's a bit like the engine usage indication, but it's much more accurate.  So we added support for MP, so multi-processor counters.  Let's put it this way.  It's GPGPU.  Well, we exposed that for GPGPU.  Right now it's only exposed through the Gallium HUD, so it's basically graphs displayed on top of applications.  So the Kepler support was added by Christophe Bermelie, our main Gallium developer.  And the Fermi support was added by Samuel Pitoise.  He was my GSoc student this year.  He also fixed the Kepler support for the other cards that Gallium didn't have.  So work in progress.  We still have to reverse engineer all the graphics-related signals.  Unfortunately, we need Windows 7 for that.  Yes, yeah, W7.  So on Windows 7, we had to port our tools to Windows 7 so as we can do the reverse engineering.  So it takes a lot of time, but it's still working on it, so this is good.  And then the performance monitoring for PDM.  Yeah, that was the usage indicator that I said should arrive shortly.  Okay, and I don't know why I didn't export the kernels.  Maybe it's just a copy paste error.  Okay, so this was supposed to be presented by Martin, but since it's not here, I'm keeping the mic.  So I talked about LibJRM2, the LibJRM rewrite, when I talked about the Kepler support that took some time to actually reach end users.  So the first thing we needed was the new LibJRM was to expose the graphic drivers address in the virtual memory.  So this is very important for GPGPU.  Without that, we couldn't do GPGPU.  So now we can.  We also support multiple threads, so multiple application per hardware context on the card,  because Nuvo uses hardware context and I've been doing so for a while.  So it means that when it crashes, then the whole desktop crashes, basically.  But we gained a lot of performance out of it.  So, yeah, and security too.  So the relocation mechanism has been reworked.  I didn't work on that and I couldn't get information on what it meant.  People forgot already.  A lot of users actually reported the no space error.  So it means that TTM couldn't find a space to put the buffer.  With this new API, it reduces that a lot.  So now I don't think we have bug reports on that anymore.  It's possibly one or two, but it's bearable cards.  Yeah, when you have no memory, of course, you cannot have a very big...  Basically when people want to drive...  Basically when people want to drive something like 10, 20p, roughly a resolution,  or 10, 2, it just doesn't work.  It doesn't have enough memory.  But yeah, that's to be expected and of course, we can't do anything about this.  Sorry about the noise.  So then, since we rewrote LIT DRM, we needed to rewrite the misadrivers.  So it was a good thing actually because the NVFX driver got rewritten.  This was a mess.  It's the driver for G4, 6 and 7 and 5.  So 5, 6 and 7, it used to be...  It used to run open arena and that's about it.  So Ben's kegs worked a lot on that and he changed the name for NV30  and it didn't fit the...  Okay, so before that it was called NV30, then NVFX and then back to NV30.  I didn't know that.  I'm too new.  So yeah, now it works much better.  It's not perfect, but it works much better.  And the naming scheme is better because we have the NV50 and C0 drivers.  So NV30 just fits nicely compared to NVFX.  Okay, that's it.  Video decoding was a big new feature added by Martin Langhorst.  He's not here, fortunately.  So he added the support for Fermi and Kepler.  I mean, it's the same thing, so basically the same thing.  So it didn't have a lot to do.  But it used to rely on...  Well, it relies a lot on firmware's.  So video decoding is done on the hardware.  So you need to send the codecs to the card so as it can decode and push everything on the screen.  So these firmware's are proprietary.  We use the Nvidia firmware's.  And we use to ask user to extract these firmware's from MMIO Trace.  And MMIO Trace is looking what is going on on the PCI Express bus or what the driver is doing.  So every interaction, as with the card, we can log it.  And from that, we can recreate the firmware's.  So needless to say, it's a pain to do that for end users.  But the reasons why we didn't ship the firmware's was because it's...  Well, we are not allowed to register or distribute them, so legal problems.  So to overcome that, Ilya Mirkin actually wrote a script to extract the firmware's from the proprietary driver.  So you just need to download it.  No need to install it.  It will extract the firmware's from the...  What we call the blob.  And then you can just use the firmware's.  So it's very easy.  On Arch Linux, we have a package for that.  It's very simple.  It takes more time of downloading and then you have the firmware's.  So it's very simple.  I don't know for other distros.  Gento has one in the pipes.  Okay.  Yeah, I don't know for Debian and Ubuntu how they are going to do that or Fedora.  But, I mean, yeah.  We did our best.  And as we don't have legal console and all that.  Or maybe we can just ask NVIDIA now if they want to allow us to register or distribute the firmware's.  Who knows.  So Ilya helped on that, on the script.  Where is it?  No.  But he also supported the support for NV50, so GeForce 8.  So now we have video decoding support from GeForce 8 to the latest cards.  So that's full support for H264, MPEG12 and another one, VC1.  Basically every hardware that supports full acceleration has it.  I believe the NV84 to NV96 which has partial support for...  It's there, PMPEG.  Yeah, with PMPEG you can get MPEG1 and 2 acceleration and it's for NV42 and NV96.  So GeForce 7 basically.  So GeForce 7 can have acceleration.  But it's crap.  MPEG2 acceleration is not useful at all.  So if you want more information, you can visit the Wiki page, video acceleration.  It's very up to date.  It will tell you what driver you need, so what you need in the kernel side, MESA and the  firmware, of course, and what the hardware actually supports.  Okay, good.  OpenGL, a few days ago.  I don't know if you saw the news, but we reached OpenGL 3.3 for NV50 and in the C0.  So basically everything after GeForce 8.  It's going to be in MESA 10.1.  So history a bit of our support.  Basically we added OpenGL 3 support in MESA 8 so whenever the Intel driver got it to work.  And we got OpenGL 3.1 in MESA 9 apparently too.  So we can't remember if it was 9 or 9.1.  So yeah, we don't remember that.  But basically we've been having a good track following the releases of Intel.  But only for NVC0.  So this is very interesting because this one has NV50 and C0 at the same time.  Usually GeForce 8, no one cares about it.  Yeah, it's getting old.  So we still have limited support for GK.  So basically the two latest Kepler cards.  And yeah, I can't remember why.  You mean the instruction set maybe?  Yeah, I believe there are some subtle changes in schedule and a few others which hasn't been dealt with.  Oh yeah, we can use this mic.  Forgot about it.  So as I was saying, I believe there is a couple changes in the ISE.  Oh, there's a new ISE which apparently we haven't had a reverse engineer support.  So that's why it doesn't work.  But I believe the primitives, it should work.  Just the more complex stuff. Shaders.  Yeah, that might take a while.  Basically you have your compositing environment and that's it.  Okay, one last thing.  So the good thing with Gallium, the Gallium infrastructure in Nuvo,  is that there is a correlation between the drivers and what we call the state trackers.  So this architecture allows us to create a new, for instance, support for OpenGL  and then all the drivers can add support for that  and they don't need to rewrite everything themselves.  So there's been a new state tracker, a DRX3D for DRX9 state tracker.  It was started by Joachim Sinholt.  I don't know this guy, but good. Thank you.  And it was completed by Christopher Bumela, our main developer of Mesa.  So we managed to run Skyrim, Civilization 5 and Starcraft 2  and we can get up to twice the FPS than Wine's DRX3D implementation.  So when you do DRX3D in the driver, it's way faster.  Good. Yeah, apparently they got better.  But I mean Wine, but I don't know.  So the announcement is here and if you want to compile it, well, you have the link.  The readme should be interesting.  I've never tried it so.  So now I hand the mic to...  Just a brief one on the compiling.  If you want to compile the branch, it's rather old.  So it should be straightforward to rebase.  But if anyone is struggling, most likely, I'll put a note at the end,  there was a guy that actually rebased it  and he did sort out a couple of small glitches along the way.  So you'll see that one shortly.  So I wanted to talk about the tools for the new driver.  I'm not developing the real driver, I'm just a tool developer.  We have a set of tools like registered database,  MIO trace decoder, assemblers and these assemblers for all the ISAs that NVIDIA uses.  NVIDIA BIOS decoder, something else.  And yes, I am taking care of the other package of tools, the NVTools that contain some of that.  There has been a lot of work on it recently.  First and foremost, we moved to a new repository.  The NVTools was previously hosted on...  on GitHub, on a path scale organization because, well,  they originally did a lot of work on it.  But it caused problems because not everybody had push access to their repo.  We had to use some people for the repo and had another repo at the source forge.  I had another private one.  So we recently cleaned that up.  We have now a new repository on GitHub where every developer has admin rights.  So it's much better that way.  Now what are we doing in NVTools?  First, we're making documentation for the NGPUs.  The project started two years ago, I think.  We just plaintexted documentation of some bits of card that we know really well  and might be interesting for new programmers.  It started with the Falcon ISA docs for one of the microcontrollers that drive the card.  We're slowly working to make it cover more of the card.  We're working quite well but slow.  But the plaintext format turned out to be...  It was nice to write but not nice to read.  So we recently moved to a new documentation system based on...  The Sphinx documentation system, the same one that Python docs use.  With Sphinx, you still write the documentation in plaintext but with a few special markup features.  Sphinx generates a nice cross-referenced HTML from it.  So you can easily browse it from your web browser.  You can just go to that URL and have a look.  And a new feature that Sphinx allows us to do is  embedding register references right in the documentation.  One of the features of NVTools has always been the register database.  It's written in XML and it contains a list of every register we know on NVDA GPUs.  It's used for several purposes.  It's used to generate headers for the other drivers with the register addresses  and values for them.  It's used to decode NMIO traces but our tool is used...  It can also be used for send-in-a-long lookup purposes.  The problem with that is that basically every register is mentioned twice in the NVTools repo.  Once in the XML database and once in the documentation.  So we're now adding support for new special markup to Sphinx  so that we can just describe the register in the plaintext documentation  and it's going to generate the XML out of that.  Another tool that was made for Nouveau is the Falcon C compiler.  Falcon is a kind of microprocessor embedded in the NVDA GPU.  It's used for many purposes including video decoding,  including graphics context switching so we can run more than one 3D application at once.  It's used for power image band.  So Sphinx Pekato made a C compiler for that ISA  so that we can write the microcode for Nouveau in C instead of doing it in assembly like now.  It's been worked on the assembly and disassembly of this.  So we just needed a compiler for that.  Right now it works only for the Pgraph firmware,  so only the context switching firmware,  but with a bit of work it should be easily acceptable to support PDMons,  which is the power management engine.  And if you want to read about it, here are some links.  And the most recent tool, the compiler,  basically to learn how some microprocessor on the NVDA GPUs work,  we have to look at the firmware for that.  Normally we don't like to the compiler things because it's basically too hard.  It's a lot of work to the compiler something and you can spend weeks just tracing some functions,  what calls what, what's the type of the structure,  and it's really slow to figure out how the hardware works by the compilation.  But normally we use MIO traces with just using on the communication between the driver and the card,  on the PCI Express bus,  but when a piece of hardware is controlled by the microcontroller right on the card,  you can just listen to what it's doing because there's no easy access to it.  So we have to just take the fervor and compile them to know what's going on.  The process has been done by hand for a long time, but that's really inefficient.  So my master's thesis is the compiler for that Falcon ISA.  It's meant to take care of all the repetitive issues in the compiling microcode.  Right now it works, it's quite well for some pieces of microcode.  We had support the full Falcon ISA, but it's enough to read the pgraph microcode.  It's written in quite an architecture in an abandoned way,  so it can be extended to support any ISA.  Right now it has support for most of Falcon and VP2 macro ISA that's used...  It's one of many controllers used in video decoding.  I just picked it because it was the easiest ISA to get going.  And, well, the results are quite nice on the ISAs.  You give it a binary, give it some hints where to start decoding,  and it spits out basically pseudo-code that has normal control structures,  it has variables, so it's much easier to read than the assembly code that we were used to.  It's still not public, it will be released soon when my thesis work is done.  Right.  But I hope you can hear me.  As I said before, my name is Emil, and I'm going to talk a little bit on the community side.  So I'm not sure how many of you are using Nuvo, how many of you are actually active or not.  I'm trying to be active, but everyone has other obligations.  So, firstly, I'm going to have a brief about the bugzilla cleaning.  So if you are aware, Nuvo used to be a user mode settings driver,  which meant that everything was done in the DDX, which wasn't that great.  So the bottom line is since we moved into the kernel, Nuvo has been a KMS-only driver.  And if you look at the bugzilla, it had dozens and dozens of bugs about the EMS driver,  and quite a lot of those weren't updated for years.  So Ilya Merkin did a remarkable job, which possibly some people hate him for,  because, oh, he closed my bug, put so much effort into it five years ago,  and then I stopped just getting bother updating it.  So what he did was he cleaned up a lot of the bugs.  He basically did a mass closure of bugs, which hasn't been updated for over the last two years, three years.  The bugs went down significantly, as you can see.  But there has been quite a few bugs I managed to get solved.  People actually said, oh, yes, I am still having the problem.  And with recent changes in kernel and everything, we can get a bit more information of, for example,  where it's crashing, what kind of a problem it is.  So, yes, as I said, there have been quite a few fixes on that.  Next thing is, I'm not sure how many of you are familiar.  Free Desktop has moved their wiki system.  And actually, it's a good thing, because there was more than enough spam.  And while doing that, there has been more than dozens of obsolete wiki articles,  and some were not that out of date.  So what Ilya and Martin over there did was basically they nuked most of the obsolete ones,  and they rewrote the cover pages, the bugzilla page.  And that one worked out very nicely at the moment, as you just go to the wiki,  you just get a nice big picture, and you see, OK, what do I look for?  Click on bugs, and we make sure we update the so-called latest version of the software,  because as you can see, there aren't that many of us.  It's not that easy to always keep on going and backporting, for example,  for MISA 9.0, where basically there's two people actually doing some work on it.  So we always recommend you try that latest software.  So, as I said, we cleaned up a lot of the craft.  There's still some in there, I believe, but if anyone's keen on doing it,  you're not then welcome to just walk into IRC, say, oh, I noticed this page, I want to help.  Great.  They will need rights for that.  But that's the problem with the new wiki system.  You need an account, a free desktop account.  So, yeah, so you can...  You need to ask for the rights.  It's not a free desktop account as in a SSH account, but still.  Yeah, that's what I said.  Basically, come to the IRC channel and tell us, okay, and basically we'll work something out.  I'm not sure what the procedure at the moment is,  but it should be almost straightforward to have a setup and working if you really want to help.  Please do.  Yes, please do, because there is a lot of stuff in there.  And not just wiki, there's a lot of stuff almost everywhere.  Well, you can get free wiki if you haven't...  If you have an SSA account, you can get free wiki if using the password generator for the wiki.  So, yeah.  Okay.  That's pretty silly.  I'm not doing any of that administration, so I'm not commenting.  You just avoided that.  I'm not doing administration.  Okay, so you definitely have heard some of these stuff.  So, at XDC 2013, they released some disclosure documentation, which meant great for us.  Additionally, there was obviously an email from NVIDIA, which clearly stated,  we want to improve the Out-of-Box experience for NVIDIA users, which is, again, great.  I believe we had one significant piece of documentation, which did cover a couple of buggy areas in NVIDIA,  possibly there's still a couple more areas which NVIDIA needs to extend because of the variety of various connectors,  especially docking versus non-docking setups, etc.  This is what the DCB-related VBO stables means, display connector blocks, if I'm not mistaken.  Additionally, one of the new guys noticed that MSI weren't working that greatly.  So NVIDIA were kind enough to provide us with some information as to which specific chipsets needed to get what,  I should say, methods to avoid any issues or having at that point.  And additionally, a very, very nice help in terms of video recording,  because William Merkin, as he was working, I believe, on the...  VP2 or VP3?  Yeah, VP2 and VP3, it was at the first few seconds of rendering and recording,  the recording was great, just it was crashing in two seconds.  And yeah, so great, that one got fixed, perfect, like more than half it's,  but I don't have such a card, at least you can use it.  What's next? Oh yes, so we're talking about TigraLand.  It's good because we did not have a few registers, as Martin mentioned earlier,  which for me doesn't ring a bell because I haven't looked it in...  Yeah, at least for power management, they have...  Many of the registers are the same, the Tigra K1 is based on a Kepler card,  yeah, for graphics, but still some engines are very similar or exactly the same,  we don't know yet, mostly a mix of both.  And then, so we have the register dumps, so it means the addresses, their name,  so the name may be cryptic, but usually it gives you an idea of what this is,  and then the values that should be stored in them, the default value,  or what means every part of the bit field, so it's very, very nice,  especially for stuff that you cannot really reverse engineer easily,  such as the hardware model for the power consumption of the card.  I wouldn't know that at one point this is just for the graphic 2D engine,  and this is for the 3D engine and all part of it,  so now we can have a proper documentation on that, which is nice.  Yeah.  Okay.  And additionally, I believe, was yesterday morning, I thought I was still sleeping  when I saw another C-patch set, which is great.  The belief provides just some very small architectural work on Nuvo,  such as that provides support for non-PCI devices.  It basically adds, I believe, a very basic support for the Tegra K1 device,  and if I'm not mistaken, so don't quote me on that,  it doesn't provide any mode settings, so...  It should work.  There is no display engine on the GPU.  Okay, so...  It's just rendering.  Yeah, so...  So yeah, basically now you can use Nuvo to work as a DRM driver for the Tegra K1.  They won't work on the user space, so 2D and 3D acceleration,  but if it's really based on Kepler, it should pretty much work out of the box with our drivers.  So we'll see, because we don't have the hard one yet.  But this would be something very interesting, right?  Yeah, definitely.  And as I said earlier, if genuinely, if anyone's willing to help,  or if it's got a few moments,  or if, for example, if you're lurking in Nuvo channel  and you see someone coming up with a trivia question,  just please help out, because there aren't that many of us.  I said it for like four times now,  and it would be great if people just come forward and say,  oh, for example, I'm very good at programming and C,  or for example, I love writing documentation.  For example, he can help out Martin with, hey, people like...  We are really looking to find someone interested in compilers,  because we suck at it right now.  Oh, yes.  And yeah, we need people for that.  And yeah, please.  But in general, whoever's willing to help,  just come forward either in the IRC channel,  or send an email of either one of us.  We rather straightforward find, if not, just give us a shout,  and we'll get you sorted.  Maybe we can give our nicknames on IRC.  Oh, yeah, mine is funny.  So is ZexAXO, is NWK, I'm NuProof, and MLMCost.  Yes.  Yeah.  Basically, that's it.  Thank you very much.  And if you have any questions?  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Questions, questions.  Okay.  I'll just take a quick question on your side.  Wait a sec.  Sorry, I just turned up.  Who's working on it on the NVIDIA side?  All of them.  You're on the side?  No, no.  Who's working on NVIDIA working on it?  I don't know.  I think you misunderstood.  NVIDIA now is starting working and improving NuVo.  Yeah.  So there are NVIDIA engineers.  We don't know them yet.  Oh, you don't know them yet?  Okay.  That's my question.  Thank you.  I can't believe we've been clear enough.  No.  Probably.  This documentation that they released in 2013,  how much would you say that it covers?  I mean, that one percent of the VBios?  No, they explained the VBios, the video BIOS,  which basically describes how the hardware is laid out  and if it has support for like,  does it have an external display connector or not?  Or is it a special media box or something like that?  And it's really helpful because a lot of those configurations  we wouldn't see in the wild.  So we can add support for something we don't necessarily have ourselves.  Anybody else?  Yeah.  And does the documentation on the BIOS also cover  old hardware or only weather-recent hardware?  Basically, when they release new BIOS,  they add support for, they add support next to the old stuff they have.  So they explain new stuff,  and in that we can work out the old stuff as well in some cases.  Like some connectors we are already using old cars,  and we saw them but we didn't know where they were necessarily.  So now we know where they are and we can add support for the old stuff as well.  Okay.  So when I run the in the war driver,  is there a chance that my graphics card may break  or are there, at least in theory, enough safeguards?  No, it could self-destroy.  But yeah, I never managed to,  and I've been heating my cards with,  oh, what's the word for that?  Herdryer.  In order for it to reach 130 degrees to test some,  well, I didn't know how it worked at the time,  but there is a dedicated part of the engine working on thermal management,  and I knew there were thresholds and all that for temperature,  and I wanted to check in the Vibios where was the temperature written,  and in the hardware,  so I had to do stuff like that and test everything,  and yes, I reached even more than that.  And the card never, I mean, it still works perfectly.  So yeah, and it's been stupid enough to do that on a Fermi,  and it's still working.  I mean, running games at 130 degrees,  it does that.  It was just desktop compositing, but still.  What?  Okay, weird.  Yeah, so it could in theory happen, but it's unlikely.  I've been torturing cards for a lot of diamonds, none of them broke, so...  Basically, I believe Martin here has second to envy the biggest collection of their cards.  If you go to a page, you're going to be just shocked by the vast amount.  I think you're missing 10 overall, or a little bit short of that.  Something like that.  50, I think.  I've run long loops that wrote random values to all their registers on cards,  and none of them broke.  So it seems rather hard to destroy a card in software.  Well, in some cases I did manage to break it, but then if I turn the power off,  and then wait for like 30 seconds for it to finally stop getting any power,  then it would work again.  So, yeah, it's very hard, but if it breaks, you get to keep both pieces.  Anybody else?  Okay, thanks a lot, guys.
_FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_0_107.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_108_155.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_156_575.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_576_791.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_792_1331.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_1332_1379.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_1380_2147.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_2148_2759.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_2760_3011.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_3012_4811.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_4812_6695.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_6696_7055.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_7056_10583.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_10584_15431.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_15432_15491.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_15492_17927.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_17928_22787.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_22788_28403.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_28404_31427.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_31428_33575.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_33576_33803.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_33804_34403.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_34404_36587.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_36588_37955.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_37956_38003.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_38004_40655.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_40656_42719.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_42720_47063.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_47064_47399.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_47400_47903.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_47904_50495.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_50496_53939.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_53940_64223.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_64224_64271.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_64272_64391.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_64392_64583.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_64584_64967.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_64968_65015.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_65016_65063.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_65064_65111.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_65112_65159.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_65160_65843.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_65844_65903.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_65904_65951.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_65952_67079.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_67080_67151.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_67152_67211.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_67212_67259.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_67260_67679.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_67680_67835.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_67836_68591.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_68592_68639.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_68640_68759.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_68760_69227.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_69228_69311.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_69312_70415.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_70416_70595.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_70596_70691.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_70692_70907.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_70908_70955.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_70956_71219.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_71220_71339.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_71340_71651.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_71652_72023.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_72024_72107.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_72108_72167.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_72168_72215.png _FOSDEM_2014__Nouveau_-_On-going_work__demos_and_research_3Bqzf4zhlvo_72216_72251.png