Nouveau Companion 40

Renouveau, Mmiotrace and User Contributed Dumps

We know that the list at http://people.freedesktop.org/~jpakkane/ren/ has not really been updated for some time, even though the web page is regenerated. The automatic script for fetching Renouveau dumps from Gmail and putting them online broke, when freedesktop.org disabled all DSA keys due to the famous security bug in Debian's OpenSSL. No Renouveau dumps are lost, though, they are still available to the developers in gmail.

Sometimes people drop by and ask if they should make a Renouveau dump with their specific card. At this point we are not burning to get new dumps, but if you can make one, please do. We would prefer dumps for 9000-series and GTX200-based cards, so basically anything that is newer than 8000-series. On the other hand, mmiotraces from all card generations are warmly welcome. At the time of writing there are 165 emails in the mmiotrace dump Gmail account, totaling in 1.5GB worth of compressed dumps.

Pmdata has improved Renouveau along the year, introducing an XML-based database of graphics commands for each card generation. Renouveau has gone through a major change due to that, now the dumping and interpreting the dump are two different steps. This means, that we do not need to dump again when a new command is identified. The command is added into the database, and existing dumps are reinterpreted. Pmdata has also written some more tests for Renouveau, and taking advantage of those requires new dumps.

After a long time, pq has managed to get Mmiotrace into the mainline kernel. The first version of in-tree Mmiotrace is in 2.6.27 and in 2.6.28 it will be fully functional as compared to the out-of-tree version. If you use these versions, use the documentation coming with the kernels. The instructions in the wiki are for out-of-tree versions of Mmiotrace. If you can choose, 2.6.28 is the preferred version.

Displays and Suspend

Malc0 has been working on perfecting the RandR 1.2 support and fixing bugs on the display mode-setting front. He started the support for suspend, both suspend to disk and suspend to RAM. The current state on suspend is that there are fairly good chances of it working for pre-NV50 hardware, but NV50 and later cards will not work. Various cards from NV05 to NV40 have been reported to work.

To try suspend, you will need to patch the DDX. If you suspend to RAM, then on resume you need to POST the card by hand (or by scripts) before switching back to X. The suspend support is still a sort of a hack, and more kernel work is needed. In the far future, when kernel mode setting becomes reality, suspending should become clean and robust.

On other things, malc0 has changed the Randr 1.2 model on pre-NV50 cards to be connector based instead of being encoder based. (Think of connectors as physical connectors, and encoders as signal sources that are routed to connectors.) So now you configure which connector you want active, and it should also ease the migration to kernel mode setting world. Malc0 has also been tuning the video BIOS parser, which is essential for RandR 1.2 mode setting and initializing the card.

Kernel Mode Setting

Kernel mode setting (KMS) means moving the display mode setting from X server drivers into the kernel. This is a general development direction for Linux graphics, and some of the end-user visible effects will be flicker-less boot, faster switching between virtual terminals and X sessions, high-resolution virtual terminals, and the ability to see critical kernel messages even while running X. From the developer side, KMS should finally end the bloody battle between various kernel and user space drivers over the control the of graphics hardware, and make the design a lot cleaner and easier to understand.

Stillunknown has made a prototype implementation of KMS for his NV50 class card to make sure the KMS API is workable, before it is set in stone. The KMS work is lead by other projects than Nouveau, and indeed there were issues, which are hopefully fixed now. Stillunknown plans to get back to it when we have a memory manager, and also sends thanks to Luc Verhaegen for giving some good ideas about
mode-setting in general and the need for abstraction. This is what stillunknown himself has to say about things:

"The first signs of KMS date from February 2008, and around April 2008 malc0 made his first attempt, mostly by copying DDX/user-space code and modifying it as needed. In all likelihood this is what will happen for NV04-NV4E. In May-June 2008, the decision was made that it's time to make sure the API is usable. It soon became apparent that the existing infrastructure followed the same ideas as Randr 1.2, which enforces a very strange driver design that does not suit most hardware. The first few attempts to convince people that something else must be done were not very successful.

Fortunately, in early June some rather important changes were made. The cloned RandR 1.2 design was moved to so called helper functions and the driver could fill a single "set_config" hook which did all mode setting. This allowed drivers to abstract away the hardware in whatever way they liked. The other major change was the adoption of connectors as the user visible objects. Before that it was an output object abused to carry connector properties. Most of the abuse went into the proper place, namely the connector. The rest (basically the link between a CRTC and a connector) went into the "encoder".

That was enough to forget about making a second KMS API and proceed by writing a prototype for NV50 class hardware using the changed API. In the process some bugs were found, but nothing serious. Steps were also taken to standardize several connector properties, such as those that indicate and select which part of a DVI-I connector is running (there will obviously be a default auto-detect mode). Another advantage of KMS is that all connector names and properties are enumerations, with no string-type names attached. This should allow for more consistent naming on the user side, and maybe even applications that "understand" what a property means, but that's all future talk.

The KMS ordeal has illustrated a fairly typical "fight" between those who think that code should follow a well thought-out design versus just hacking away. To this day it seems that the few drivers that exist use the Randr 1.2 style helper functions, which indicates the intervention was necessary. The prototype for NV50 class hardware is not bad and will be finalized once a useful memory manager becomes available for Nouveau."

Stillunknown has also taken a look at the mode-setting equivalent of a FIFO. It works much like a graphics FIFO, just lacking multiple objects. He has looked at that several times, but it has proved to be a non-trivial effort getting it to work. Interesting registers, including the PUT and GET registers have been isolated, but the contents of some other registers remain a mystery, unfortunately. It seems that there even is more than one FIFO available, quite how many is unknown. This functionality is not expected to work in the foreseeable future, but it is not a disaster, because the hardware offers indirect access via two MMIO registers. It is however possible that a functional tiled frame-buffer depends on this FIFO, but until proven otherwise this remains a guess (Note: The lack of a tiled frame-buffer is the reason why a compositing manager is needed for NV50, the 3D engine cannot render to a linear buffer and the compositing manager ensures that windows have a back-buffer, which can be rendered to). For the moment it is very useful to know that a mmiotrace dump does not tell everything about mode-setting, instead valgrind-mmt can be used to trace user-space FIFOs.