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
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
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.
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
Videos are here: http://radeonhd.org/?page=fosdem_videos
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.