Nouveau Companion 38

In the first Nouveau Companion this spring, the free software developers reverse-engineering the NVIDIA Linux driver have provided a new status update. Most of the progress recently made to this open-source X.Org driver is for the NV50 GPUs found on the GeForce 8 and 9 series. There is a new test program for directly communicating with NV50 processors and that these newer graphics cards have reached the milestone of being able to render an object with this driver. Approaching soon is supporting the TTM memory manager with Nouveau. The open-source Nouveau developers are hoping to get some Google Summer of Code students working on XvMC support and suspend-and-resume along with a simple Gallium3D backend for the NVIDIA NV2x ASICs.

Nouveau Companion

Roughly three weeks have passed since the last issue and so it is time to update you on our current status.

Well, there is clearly a pattern in us trying to get a Summer of Code slot each year: Get active only if the deadline for application submission is not far away (that is less than 7 days). Well, the deadline was extended to Monday, the 7th of April so you still have a chance to get in. Get in touch with us in case you are interested.

This just happened once again this year with us scrambling to get students to apply for a Nouveau project. What we have is:
- yeknom (Suspend / Resume for NV4x)
- riverbank (Simple Gallium3D back end for NV2x chip sets)
- Some XvMC support for Nouveau
- Generic GPU-Accelerated Video Decoding. This one is not directly related to Nouveau, but would be beneficial to us too.

Stillunknown got the money for an 8400GT card donated by mycroes so that he can now work on NV5x mode setting too. I am not sure whether stillunknown is grateful or whether he curses that fact, though :)

Nevertheless, mycroes thank you very much for that generous donation.

All in all the weeks around Easter were a bit on the slow side. Lots of personal stuff for some of our developers plus the Holiday itself asked for some social interactions.

So without further delays: Let's start with the real content.

The Current Status

OK, with stillunknown now having his own NV5x card, he started to gather information about the current NV5x status. He started tidying up and deobfuscating some mode setting code we inherited from nv. Hot plugging DVI monitors is next on his agenda. For that (and for other mode setting endeavors) he is currently investigating the interrupts, which are emitted by the card.

pq changed our current status while ahuillet and stillunknown updated the status matrix. Texture and Lighting was set to N/A as at least from NV40 on this is done through shaders. Same should be true for NV30 too.

pq is still working on the patches to get MMioTrace ready for mainstream. There are still some bugs, maybe even in the underlying ftrace kernel code but progress is being made. Single CPU does work with patches on latest 2.6.25rc kernels found here. SMP however may result in errors like "recursive probe hit" or lockups.

Regarding lockups: It seems that the blob with 169.x and up is traceable again with MMioTrace (with MMioTrace for older kernels). So if you want to trace NV5x cards, please use a recent binary driver.

Malc0 has been experimenting with mode setting in the kernel. He implemented a very basic nouveaufb (Nouveau Frame buffer driver) for NV04 - NV4x. It provides an fb console and allows X to start using the FBDEV driver. Mode setting is done in the kernel but currently no acceleration is provided.

Malc0: "Might be worth [...] noting that it's also fantastically ugly code :-D I took a 'how little can I do, to get this working' approach". This driver was only a proof of concept and will be fleshed out into something better now.

Next up to Marcheu who just finished building his new computer with that shiny new NV5x he got donated (see last issue!). Before moving to NV5x coding though, he wants to get some features done:
- NV1x before finally handing over the code to p0g he wants to get the architecture right. glxinfo doesn't crash anymore. Next up: Getting the state atoms (objects) right. After that p0g should be more than able to get everything in shape.
- Then some fixes may be needed for NV3x to get the architecture right, too.
- Then finally, it is time for NV5x coding.