Nouveau Companion 36

Another topic over the last few issues is MMioTrace and its inclusion into the mainstream kernel. On LKML it was suggested to move it to a new framework in the kernel: "ftrace". It is mainly developed by Ingo Molnar and Steven Rostedt but I don't know of any web page giving more details. The only thing is a README.

Ftrace offers all kind of kernel tracing facilities and allows other modules to plug into it, build on it and offer additional features. MMioTrace is going to be one of its first users. Currently the kernel guys and pq (for MMioTrace only) are aiming for kernel 2.6.26.

The discussion of the current version of MMioTrace on LKML can be found here.

Ok, now for the usual assortment of short topics:
- benkai is spending some time on trying to get Suspend / resume for nouveau working. Currently he is in a "trial and error" phase and not sure whether he can succeed. He summarizes his findings here.
- After Marcheu finished his initial work on NV30 and he started working on NV1x Gallium. After finishing a basic driver for that card (e.g. missing texturing) he wants to buy an NV5x card and get going there (Editor: Yay!).
- Malc0 tried to fix some PPC related Randr1.2 problems. Kelnos tried his fixed and reported good results. Only remaining problem was Nouveau thought Kelnos would have a dual_link LVDS. When disabling that configuration bit, Nouveau worked fine even with text mode. Additional help came from sbriglie and moondrake which led to additional hints about the failure and fix.
- Nouveau get build via the tinderbox service from FreeDesktop.org. Current status: Green.
- Marcheu went through the heap of cards he owns and tested them for Randr1.2 compliance. He found a few bugs with NV4, NV11 and NV20 (Bug numbers #14820 to 14825) of which at least one was fixed within a few hours after Marcheu creating the reports.

Therefore, Randr1.2 is working on most configurations and NVidia hardware now, with only a few issues on NV11 and NV17 left. In fact it is working so good that Marcheu is pushing Malc0 and Stillunknown to make the Randr1.2 code default for Nouveau.

Current planning is about one month or sooner to switch the default setting, an additional month for backup reasons until the old code is removed. A short while after that we may start moving our mode-setting code into the kernel. However, that would mean that we would need then current DRM to support that plus TTM which is a requirement for mode-setting too.

Help Needed

As always: Look on our TestersWanted page. And as we want to ramp up NV5x based development: Please contact us, if you have hardware available and would be willing to donate (any kind of 8x00 card and / or PCIe motherboards).

In case you need help with Nouveau, please consider mailing to our mailing list or opening an entry in Bugzilla. It is unlikely to get support on the IRC channel, which is reserved for development talk.

Special: FOSDEM 2008

Ok, on the last weekend of February there was FOSDEM at Brussels. Unfortunately, I wasn't able to attend but we have some links for you about Marcheu's talk:

Videos are here: http://radeonhd.org/?page=fosdem_videos or ftp://ftp.suse.de/private/bk/fosdem-2008/fosdem_2008_nouveau-720x576-v[234].ogg.
The slides of Marcheu's talk: http://icps.u-strasbg.fr/~marchesin/nvdri/fosdem2008.pdf

However, that's not all, let's start pestering Marcheu and with questions how the event went from their point of view.

TiNDC: How was the interest in the talk and how was it received?

Marcheu: I think the talk was well received. We had a fair number of people attending, and they agreed that eating fruit was good for one's health. Eating fruit and going to the sauna in the X.Org development room are two activities that keep people fit!

TiNDC: In your talk you presented a Gallium3D solution for older, shader-less cards. Could you elaborate a bit on that as I totally missed any reference to that topic in the logs. Thus there was no mentioning of it in the TiNDC until yet.

Marcheu: It's just a bit of plumbery to handle fixed function cards through the Gallium infrastructure. There is more to gallium that just the programmable pipeline stuff, so I think it's worth reusing the framework even in the context of fixed pipeline cards. I had given it a first try some months ago, but wrote the gallium part first, which was a mistake. I realized a bit late that it doesn't make sense to do such changes out of nowhere; you have to test those on a driver. I'm now approaching the problem from the other side, by doing a simple gallium nv10 driver first (without textures for example).

TiNDC: How does it work? How do you support shaders on cards which have none?

Marcheu: For the programmable pipeline, the state tracker emits shader instructions, which implement fixed OpenGL state. For fixed pipeline, the state tracker translates the same OpenGL state into new instructions, which are fixed-functions shaders. These instructions represent the fixed pipeline functionality, and are stored just like other shaders, and therefore the internals of gallium do not need to change. Only the front-end and back-ends of gallium need to be adapted to handle the additional instructions. This is the most straightforward way of achieving this.