Nouveau Companion 43

FOSDEM Coverage

Well, it was that time of the year again, and once again I have relied on others to give me information of what happened.

Marcheu did two talks this year: About the state of Nouveau and about Gallium and its LLVM usage.

Questions to Marcheu:

Q: It seems to work fine as is, I rarely see serious problem reports anymore. What is your point of view?

A: Yes, our 2D accel is mostly stable, and has seen nice performance improvements recently with EXA core changes. Hopefully that code will require less attention over time, and we can focus on the 3D bits instead. However, EXA changes are still required on NV50...

Q: What is barring us from finally releasing a 2D only driver?

A: As always, the kernel interfaces. If we merge our DRM into the kernel with [an] unfinished interface, we will have to maintain them forever. In order to ease our burden later on, we will only merge when we are happy with these interfaces. So, merging our DRM into the kernel requires:

- finishing KMS
- finishing memory management
- stabilizing the DRM interface
- having newttm merged into mainline kernels
- finally, having the Nouveau DRM merged into the kernel

Q: So what about Kernel Mode Setting?

A: Hmm, you already talked about it above, what should I add to this? :) But we can say that it is starting to work on NV50 cards, and that the NV04->NV40 RandR 1.2 code should be pretty straightforward to port to the kernel. The point of concern lies in the bios parser though, which remains incomplete as of today.

Q: Is VT Switching finally fixed?

A: It should work, it's only temporary breakages that just happened the last couple of months :)

Q: Recently backlight support for some NVidia cards were added by Matthew Garrett and I seem to remember he is working on some kind of suspend / hibernation too?

A: Matthew is working on power management for all cards. So he splits his time between different graphics hardware, it's not Nouveau-only :)

As far as suspend/resume goes, we need to be able to execute the BIOS script language to resume a card (the same one that's unfinished for mode setting). Stuart is currently working on this, and cards up to and including NV40 should suspend/resume mostly once we enable it (testers are welcome of course, as this is a touchy issue). For NV50 we lack someone working on this, so these cards don't make it out of suspend...

Answer from Matthew Garret:

As far as suspend/hibernate support goes, there's two main types of problem. The first is that on resume from RAM the card is usually completely uninitialised. Reinitialising the card can be achieved by either executing code from the legacy video BIOS in an x86 emulator or by executing the NVidia BIOS tables in an interpreter. The first doesn't work on most NVidia cards - after the initial POST the bios rewrites itself so the entry point simply exits. The second is achievable on pre-g80 cards, but has not been made stable yet. Simply executing the scripts is insufficient, as some register state needs to be saved and restored across the suspend/resume in order to allow the scripts to run properly. The scripts have not been sufficiently reverse engineered on G80 and later hardware to be able to work on this.

The second suspend-related problem is restoring the state of the acceleration hardware. Reinitializing the card is adequate for un-accelerated 2D operation (as provided by the "nv" driver), but if the acceleration state is not restored then switching back to X may cause the X driver and card to have inconsistent ideas of the world. At that point, the system may crash.

I've done some work on reinitializing the cards on pre-G80 hardware, though it only seems to work on my machine so far. I've done nothing on the acceleration restoration side of things.