Nouveau Companion 40

Gallium3D Progress

Some time ago there was the Mesa DRI driver model, where drivers were implemented directly between the OpenGL API and the hardware. This made the drivers big, complex and redundant. The Nouveau 3D driver was started for that old model, and it evolved fairly far in that most card generations were able to run at least glxgears. Then came the Gallium3D infrastructure, and the project was set back miles on 3D support. However, the Gallium3D model is far better than the old model. The user API, for instance OpenGL, is abstracted away and the drivers only need to implement a single core API, making the hardware drivers small and clean. Well, this statement is a simplification, but you can read about Gallium3D design.

As you might know, NV40 Gallium3D is currently the most advanced part of Nouveau, and some people claim to have played Quake 3 Arena with it. Do not jump for joy now, because the mantra still holds: Gallium3D is not supported yet, and we do not want bug reports about it. Of course, unless the bug report has a patch attached, that fixes the problem. Otherwise, trying to test it will likely lead to trouble, and we really do not want to waste the developer time or nerves on discussing something that is known to be broken. On the other hand, if you plan to contribute code, then come to talk with us already!

Pmdata has been developing NV30 Gallium3D after Marcheu started it. Pmdata followed what was happening with NV40 Gallium3D and made similar changes, because the Gallium3D APIs were still a bit in flux and somewhat uncharted territory. Pmdata records his progress on his personal Wiki page, so you should check that for news and images. Judging from the xmoto screen capture, geometry processing is working, and there are even textures, although the textures are swizzled when they should not be (or vice versa). Uploading properly swizzled textures has proven to be a little harder than he first thought. He has also made nv30_demo program, which pokes the card directly to try rendering commands.

Development on NV10 Gallium has been quiet for some time, and so has NV04. It is interesting to recall, that NV04-NV20 family range does not have real fragment shaders, and NV04-NV10 families do not have vertex shaders, but Gallium3D is built on the assumption that shaders do exist. Marcheu has investigated how these fixed pipeline cards could be used in Gallium3D, and it seems possible, but he has yet to make his mind about which approach is preferable. It could mean changes throughout the whole Gallium3D stack, or not.

Someone has yet to start NV20 Gallium3D work, there is currently nothing. It can be bootstrapped by copying in the NV10 Gallium bits and adding NV30 Gallium vertex program bits.

Darktama has started NV50 Gallium3D, but it does not do anything useful at all, yet. For instance, textures do not work. After doing NV50 2D work, he says he now has a much better view on how to implement things, and will get back to it when he can.

Marcheu has recently been working with LLVM, that should optimize shader programs to the max. But, his work has been with x86 LLVM, specifically the SSE instruction set, and not with GPU instruction sets, for vertex programs. Why would one want to do vertex processing on the CPU? The answer is two-fold: early cards do not support vertex programs, or their fixed vertex pipelines are not worth the trouble to use, since modern CPUs do vertex processing faster. The trouble in using the fixed vertex pipelines is the adaptation of Gallium3D, so if that can be skipped, the better. CPU vertex processing is also required, when the vertex shader is so complex, that it cannot be realized on a GPU that does support vertex shaders. On the other hand, Gallium3D must be adapted to make use of fixed fragment pipelines, since there is no point trying to do that on the CPU, it would not be fast. Marcheu says the LLVM/x86-SSE vertex processing works, but the software fragment pipeline (a.k.a softpipe FP) he has to use at this point is a nest of bugs.

The major bottleneck in Nouveau's Gallium3D development is the lack of developer time. Granted, the current simple memory manager easily runs out of memory and falls over, but it is still enough to try and implement almost all 3D functionality.

Memory Management

The DRM has historically had a plethora of simple memory managers, and so does Nouveau have one currently. However, a full-featured memory manager is required for efficient use of resources, and previously this was supposed to be TTM (Translation Table Maps). Darktama had been working to that end, when Intel developers came up with GEM (Graphics Execution Manager) after trying for a year to get TTM going well enough on integrated Intel graphics. In the process the TTM user API was removed, and now Nouveau and also Radeon are going to use GEM. Actually, GEM is little more than just an API, and it needs a backend, so TTM will still be used internally. Darktama says, that not much work was wasted in the transition, since TTM is still around.

Darktama is practically our memory manager developer and he puts all the time he can afford into making Nouveau use GEM (and TTM). The "ng" branch in the DDX git repository is a part of his GEM playground, where he is trying things out and figuring out a proper design. Other parts of that playground are a DRM branch "ng", which is based on the DRM branch "modesetting-gem", and nouveau/mesa repository's "gallium-0.2-ng". Darktama does not yet know, if that work will ever be merged into "master", or does it need to be rewritten after he has learnt what needs to be done. He has worked with NV40 and says that apart from rough edges, it is already working "fairly OK". Performance is not at the same level as with the simple memory manager in "master", but the new work should solve the various out-of-memory errors the current Gallium triggers. It also makes the 3D code interact well with the 2D code, in that moving a 3D application around on screen does not leave trashy trails. All in all, darktama is fairly happy with it, but it is definitely not ready to be merged into Nouveau mainline.