The irregular Nouveau-Development companion

Issue for April, 5th 2008

Intro

Editor: This one is slightly updated to the version from Phoronix as there were some incorrect facts plus Marcheu disagreement of how to render ended up at a totally wrong section in the text, giving a totally incorrect impression. Other than that, nothing new.

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, 7th 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 got 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 a 8400 GS card donated by mycroes so that he can now work on NV5x mode setting too. I am not sure 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 works, but he wants information about various interrupts generated by hot plugging, so that is next. 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: http://www.nvnews.net/vbulletin/showthread.php?t=110088 SMP however may result in errors like "recursive probe hit" or lockups.

Regarding lockups: It seems that the blob with 100.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. So now that we have covered Marcheu, stillunknown, pq and Malc0 let's see what Darktama was up to.

Well, he wrote a test program to talk directly to the NV5x hardware. That program is able to render triangles ignoring the non existent DRM support for NV5x for now.

That may not seem to be much, but it is a first: The proof that we (well, Darktama) can get the 3D engine to not only clear something (Milestone reached last issue) but render to something too. That was not an easy one, let's give him a pat on the back :)

Not to be accused of laziness, Darktama continued his work on NV4x too. That won't take much longer though because we are nearly done with 3D on NV4x. Currently there are only two major issues remaining:

The memory management isn't using TTM yet. This will result in otherwise working OpenGL clients to crash out soon after start. How soon (or if at all) depends on the program and the hardware used. Rest assured, though: It will crash often.

The other problem is that every time we render we have to flush commands straight to the GPU, which is bad for a number of reasons:

• GPUs performance is best when they can process large batches of commands
• with TTM it'll become far too many kernel calls for my liking Currently when rendering a scene, the driver will do: clear (maybe up to 3 times), flush, render, flush, swap buffers, flush which each flush meaning entering the kernel when using TTM. That is obviously not the best solution, so more thought is required here. Marcheu is sure this can be done differently, keeping objects much longer "pinned" by the TTM. That needs some more technical investigation

That 3 times clearing needs some explanation though: That has to do with how Gallium handles some clears, it "bypasses" the driver and does them with quads separately for each buffer. That's bad when NVidia hardware is capable of far better methods.

Regarding TTM: Apart from the problem noted above, Nouveau is nearly TTM ready. Basically someone could "just" start to (ahem some driver knowledge needed) plug the calls from Nouveau to TTM.

Before you run and starting cheering: There is still some work left, we still have to deal with problems on our side (which I got covered for this issue) as well as with problems on the Gallium side of things.

For example, when trying to get reflections working, we noticed that this isn't easy to do with current Gallium. Shortly put: On NVidia it is currently impossible to get glClipPlane() functionality without using shaders. However, exactly that is an assertion of Gallium. Only solution for now: A software fallback, which slows things down quite a bit (Try Neverball with and without reflections if you are curious). Darktama has a patch ready for Gallium which is currently review by the Mighty Ones of Gallium. Have a look here for a more detailed explanation:

http://people.freedesktop.org/~marcheu/irclogs/nouveau-2008-03-29#1425

Other topics, which are worth mentioning:

• Malc0 fixed the broken back light code for Apple laptops.
• Some tests for NV5x mode setting and reverse engineering 3D rendering
  • were done <<< Previous Issue | Next Issue >>>