So, today we'll be talking about Nuvo 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 Emil Velikov and Martin Akosianliki.

We were supposed to have Martin Langkost, so three Martins, but yeah, he's not here. Okay, so the reason for this talk is, last time we discussed about the updates on Nuvo was at FOSDEM 2012.

We've done another one at XDC, but it's not FOSDEM, so let's do it here too. And of course, there were many improvements since then, so yeah, I'm with that. 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 Scaggs in advance,

so he had the card for 15 days to prepare for the same day release. And then, there was some unreleased 3D support, that happened a few days after. But as we were in the middle of rewriting the MISA driver,

with the new Leap DRM, 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, Nuvo 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 used to work, 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 trash all the others. So, the new core architecture is now separated in per chipset.

It's very... It's easier to know what are the dependencies and... 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 kind of stuck. It used to be impossible. Okay. Next thing, Optimus and Prime support. So, Optimus is the technology developed by NVIDIA.

They use an Intel GPU and then an NVIDIA card. Usually, it's the Intel GPU doing all the display and the 2D acceleration and 3D too, but 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 are 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 blating 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.

So, if you want to have more information, you can have a look at the wiki. The wiki page on Optimus. So, power management. Thermal management should be working on almost every card now. So, it means temperature monitoring.

There used to be so many ways to get the temperature on the card. It's crazy. Especially on GeForce 7 cards where we are 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 GeForce 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 hwmon architecture, which is used to export probes. 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, GeForce 8 to Fermi, so GeForce 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 SC 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 OK+. 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.

So, let's continue on power management. Reclocking. You've been hearing about this for a while on every forensics article about nouveau. Michael complains about a 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 too, 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 clocks 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.

So, quite a performance hit. Then, power and clock gating are ways to lower the power consumption without 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. Seems like NVIDIA is just putting numbers and there's no logic in it, so we'll try to use that. If users complain too much, then it means that it doesn't work, because that's the only way we can test.

It should be released soon for Fermi and Kepler because of some code that has been released for the Tigra K1. 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. Only a third. I was wondering why I didn't have the same power consumption. Okay, performance and power monitoring.

The big thing is that some Kepler actually have a power sensor now. They used to have an internal hardware model of the card, 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, you get a power consumption reading. You get it about 500,000 times per second, which is quite nice for power copying, but we won't talk about that. We should soon have a rough engine usage indication,

so for memory, graph is the graphic engine, and video, oh yeah, the video decoding engines, and that's going to be used for dynamic re-clocking, 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 Galium HUD, so it's basically graphs displayed on top of applications. So, the Kepler support was added by Christophe Bermiller, our main Galium developer, and the Fermi support was added by Samuel Pitwazi.

He was my GSOC student this year. He also fixed the Kepler support for the other cards that Galium 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. 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 driver's 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 applications 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 gain a lot of performance out of it.

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. Possibly one or two, but... 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 a 1020P, roughly a resolution on 1022, it just doesn't work. It doesn't have enough memory, so... 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 libdrm, we needed to rewrite missile drivers. So, it was a good thing, actually, because the NVFX driver got rewritten. This was a mess.

It's the driver for Geforce 6 and 7. And 5, okay. So, 5, 6, and 7. It used to run OpenArena, and that's about it. So, Ben Skeggs worked a lot on that, and he changed the name for NV30 to 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, 30 just fits nicely compared to NVFX. Okay, that's it. Video decoding was a big new feature added by Martin Langhorst, which is not here, unfortunately.

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 filmwares. 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 filmwares are proprietary. We use the NVIDIA filmwares. And we ask the user to extract these filmwares 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 it has with the card, we can log it. And from that, we can recreate the filmwares. So, needless to say, it's a pain to do that for end users.

But the reasons why we didn't ship the filmwares was because it's, well, we are not allowed to redistribute them. So, legal problems. So, to overcome that, Ilya Mirkin actually wrote a script to extract the filmwares from the proprietary driver.

So, you just need to download it. No need to install it. It will extract the filmwares from what we call the blob. And then you can just use the filmwares. So, it's very easy. On Archinex, we have a package for that. It's very simple. It takes more of the time of downloading.

And then you have the filmwares. So, it's very simple. I don't know for other distros. Gen 2 has one in the pipes. And basically, that's it for things. 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.

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 redistribute the filmwares. Who knows? So, Ilya helped on that, on this script. Where is it? 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. So, for H.264, MPEG 1.2, 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, PMPG. So, with PMPG, you can get MPEG 1 and 2 acceleration. And it's for NV40 to NV96.

So, GeForce 7 basically... So, GeForce 7 can have acceleration. But it's crap. MPEG 2 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. So, it will tell you what driver you need. So, what you need in the kernel side, Mesa, and the filmwares, 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 NVC0. So, basically, everything after GeForce 8. It's going to be in Mesa 10.1. So, there is 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.91. So, yeah, we don't remember that. But basically, we've been having a good track at 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, well, basically, the two latest Kepler cards.

And, yeah, I can't remember why. New instruction set, maybe? Yeah, I believe so. I believe there is some subtle changes in the schedule and a few others, which hasn't been dealt with yet.

Oh, yeah, we can use this mic. Forgot about it. So, as I was saying, I believe there is a couple of changes in the ISA. I'm not too familiar. Oh, there's a new ISA, which apparently we haven't added support. Yeah, reverse engineered or added 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 Galium, the Galium infrastructure in Nuvo, is that there is a de-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. There's been a new state tracker, a direct 3D for DirectX 9 state tracker. It was started by Joakim Sinhalt. I don't know this guy, but good, thank you.

And it was completed by Christopher Beumiller, so our main developer of Mesa. So, we managed to run Skyrim, Civilization V, and StarCraft II and we can get up to twice the FPS than Wine's direct 3D implementation.

So, when you do direct 3D in the driver, it's way faster. Good. Apparently, they got better. 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, now I hand the mic to… Just a brief one on the compiling. If you want to compile the branches, it's rather old. So, this 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. You'll see that one shortly. Yeah.

So, I wanted to talk about the tools for the nouveau driver. I'm not developing the real driver, I'm just a tool developer. We have a set of tools like register that database, MMI with race decoder, assemblers and disassemblers for all the ISAs that NVIDIA uses, NVIDIA BIOS decoder, something like that.

And, yes, I'm taking care of the other package of tools, the NVTools that contains all 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 GitHub, on 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 the repo.

We had to use some people for the repo and had another repo as the source for which 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 NVTools. The project started two years ago, I think. It started as just plain text 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 drives the card. We're slowly working to make it cover more of the cards.

It's going quite well, but slow. But the plain text 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,

and the same one that Python docs use. With Sphinx, you still write the documentation in plain text, but with a few special markup features. Sphinx generates a nice cross-referenced HTML format, 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 registered references right in the documentation.

One of the features of NVTools has been always the registered database. It's written in XML, and it contains a list of every register we know on NVIDIA GPUs. It's used for several purposes. It's used to generate headers for the other drivers with the registered addresses and values for them.

It's used to decode NMIO traces, but our tool is used... It can also be used for similar 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 plain text documentation,

and it's going to generate the XML out of that. Another tool that was made for Nuvo is the Falcon C compiler. The Falcon is a kind of microprocessor embedded in the NVIDIA 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 management. Excellent.

Shinkui Kato made a C compiler for that ISA so that we can write the microcode for Nuvo in C instead of doing it in assembly like now. Because he 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 extendable to support PDMons, which is the power management engine.

And if you want to read about it. The most recent tool, the compiler. Basically, to learn how some microprocessors on the NVIDIA GPUs work, we have to look at the failures for them.

Normally we don't do the compiler things because it's basically too hard. It's a lot of work to compile something and we 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. Normally we use MIO traces which just release 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 failures 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 decompiling microcode. Right now it works quite well for some pieces of microcode. It doesn't yet support the full Falcon ISA, but it's enough to read the p-graph microcode.

It's written in quite architecture independent way, so it can be extended to support any ISA. Right now it has support for most of Falcon and VP2 macro ISA.

It's one of many controllers used in video decoding. I just picked it because it was the easiest ISA to get going. The results are quite nice of 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 codes that we were used to.

It's still not public. It will be released soon when my thesis work is done.

All right, 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. 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. Firstly, I'm going to have a brief about the bugzilla cleaning. 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.

The bottom line is since we moved into the kernel, Nuvo has been a KMS only driver. If you look at the bugzilla, it had dozens and dozens of bugs about the KMS driver, and quite a lot of those weren't updated for years.

Ilia Merkin did a remarkable job, which possibly some people hate him for, because, oh, he closed my bug. I put so much effort into it five years ago, and then I stopped. I didn't 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, yay! 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 outdated.

So what Ilia 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, okay, 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, for example, for

MISA 9 point something, where basically there's two people actually doing some work on it. So we always recommend you try the latest software. So as I said, clean up a lot of the crap. There's still some in there, I believe, but if anyone's keen

on doing it, more than welcome to just pop into IRC, say, oh, I noticed this page, I want to help. Great. They will need rights for that, so that's the problem with the new wiki system. You need an account, a Free Desktop account.

So you need to ask for the rights. It's not a Free Desktop account, as in an 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 it set up and working if you really want help. Please do. Yes, please do, because there's a lot of stuff in there, and not just wiki, there's a lot of stuff almost everywhere. Well, you can get free wood if you have an SSA account, you can get free wood if using the password generator for the wiki.

So, yeah. That's pretty silly. I'm not doing any of that administration, so I'm not commenting.

You're just aware of that. I'm not doing administration. Okay, so you definitely have heard some of these stuffs. So, at XDC 2013, they released some undisclosed documentation, which meant great for us.

Additionally, there was obviously an email from NVIDIA, which clearly stated, well, we want to improve the out-of-box experience for Nuevo users, which is, again, great. I believe we had one significant piece of documentation, which did cover a couple buggy areas in Nuevo.

Possibly, there's still a couple more areas which Nuevo needs to extend, because of the variety of various connectors, you see, especially docking versus non-docking setups, etc.

This is what the DCB-related video stables means, display connector blocks, if I'm not mistaken. Additionally, one of the Nuevo 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, shall we say, methods to avoid any issues we were having at that point. Additionally, a very, very nice help in terms of video recording, because Elon Mirkin, as he was working, I believe,

on the VP2 and VP3, it was, at the first few seconds of rendering and coding, the recording was great. Just it was crashing in two seconds.

And, yeah, so, great, that one got fixed, perfect. More than happy, despite that I don't have such a card, but at least you can use it. What's next? Oh, yes, so we're talking about Tegraland. It's good because we did notice a few registers, as Martin mentioned earlier, which, for me, doesn't ring a bell, because I haven't looked at it.

At least for power management, many of the registers are the same. The Tegra K1 is based on a Kepler card

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 parts of it, so now we can have a proper documentation on that, which is nice. And additionally, I believe it was yesterday morning, I thought I was still sleeping when I saw an RSC patch set, which

is great, I believe it provides some very small architectural work on Nuvo, such as, that provides support for non-PCI devices. It basically has, 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... Oh, okay. It's just rendering.

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 hardware yet, but this would be something very interesting, right? Definitely. And as I said earlier, if, genuinely, if anyone's willing to help, or has got a few moments, or if, for example, if you're lurking in a 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've 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 in 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. 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.

It should be rather straightforward to 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, Iz, Zek Zekzo, Iz, NWK, Amu Proof, and Emil Ankost.

Yeah. Basically, that's it. Thank you very much, and if you have any questions...

Sorry, I just turned up. Who's working on it on the NVIDIA side? All of them? You're being hired? No, no, no. From the... Who's working on NVIDIA, working on it? I think you misunderstood. NVIDIA now is starting working on improving Nuvo.

Yeah, yeah. So, NVIDIA engineers, we don't know them yet. Oh, you don't know them yet? Okay, that's next to my question. Yeah, but, yeah. Thank you.

I can't believe we've been clear enough. No. This documentation that they released in 2013, how much would you say that it covers?

.1%? 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?

And does the documentation on the VBIOS also cover old hardware, or only rather recent hardware?

Basically, when they release new Bios, they add support next to the old stuff they have. So, they explain new stuff, but from that we can work out old stuff as well in some cases. Like, some connectors were already used in 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 in the Wotriber, 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? Hair dryer. 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 VBIOS 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 he's been stupid enough to do that on a Fermi, and it's still working. I mean, running games at 130 degrees, he 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 time, and none of them broke, so... I believe Martin here has second to NVIDIA, the biggest collection of their cards.

If you go to his 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. 15, I think. I've run long loops that wrote random values to all their registers on the 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 turned the power off and then waited 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.