The irregular Nouveau-Development companion
Issue for March, 21st
1. Intro
Hello, you are going to read issue #37 of TiNDC. If you expect this issue to be as long as the last one, please prepare for some disappointment. We will get back to the normal length this time.
All in all, not much obvious progress to report, as people try to get to grips with Gallium or are working to get Gallium working on their cards. If you feel brave, you can try it out according to Hanno Boeck's blog (http://www.hboeck.de/archives/599-A-try-on-current-nouveau.html) or have a look at our Wiki page: http://nouveau.freedesktop.org/wiki/GalliumHowto
Please note that we can't and won't give you any support for this yet. If it works, you are lucky, if not, please don't complain. There are known bugs in both Nouveau and Gallium and we are working on it. But we have just started...
The question was raised whether Nouveau would be manipulating things like fan speed. Answer is: No, please use Thunderbirds NVClock for that kind of work.
Last topic for this introduction: We got a 8400 card donated by kho. This card won't leave the greedy little hands of Marcheu who will join Darktama's efforts to get 3d on NV50 cards going. Thanks you very much kho for your generous donation!
GSoC 2008 saw Xorg accepted as a mentor organization. Depending on the results from the last two years we are not that optimistic that we could get a slot with Xorg mentoring us. If it works out, we would like to work on NV5x, so if you have a spare 8x00 card you could donate, please come forward. And no, we don't expect you to donate a 8800 GTS or 9x00 card. Another 8400 or 8500 card would suffice!
And as this got asked a few times on IRC: We consider the latest G92 cards to be part of the NV50 family and we will support them in the future. Please note, that currently there are drawbacks (more on this in the next chapter).
2. The Current status
As we hinted at in the last issue, kernel mode setting is going mainstream soon. Fedora 9 will be there first, getting the necessary plumbing first (http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-03-06.htm#1251)
Stillunknown and Malc0 continued cleaning up and fixing Randr1.2. Its code path for NV50 were cleaned up to as there was much cruft accumulated. The new edition is now more in tune with the code for the other cards. However, no new functionality was added, only obvious problems were fixed (please note, that neither Malc0 nor Stillunknown have a NV5x card available). So, the code works as well (or as bad) as before.
Still there seems to be some hope: The Xorg-NV got code to parse the BIOS tables of the NV50 based cards. Maybe malc0 will be able to adapt it to our code base. What comes out of it remains to be seen, though.
Beyond that, the time frame for Randr1.2 was mainly confirmed if no real showstoppers rear their ugly head. By the way, Nouveau does not crash when exiting X. It simply tries to restore text mode and fails horribly, leaving an unusable text console.
Airlied tested (http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-03-12.htm#0053) PPC Gallium and had some problems with the depths buffer. Further inspection by Darktama and Marcheu hinted at a possible problem in Mesa for PPC. There seems to be a problem with the depth buffers. Look at the green gear for the problem:
Darktama did some work on NV30 helping pmdata to get the card init going. "I just put the NV30GL in for the fun of it, and fixed the main issues, the rest is up to pmdata now :)"Benkai is still working on summarizing options, problems and possible solutions barring suspend support for Nouveau. After that he started working on testing suspend / resume functionality on NV04 by hacking the code for suspend into EnterVT (Switch to text console) and for resume into LeaveVT. So when entering text console, the status was saved and restored when switching back to X.
For that functionality, an ioctl() was added to the DRM and PGRAPH proved trivial on NV04: Nouveau simply allocates a channel and call s engine->graph.save_context() before PGRAPH init. For resume a call to engine->graph.restore_context() was sufficient. After that Nouveau was working after a LeaveVT/EnterVT (with PMC/PTIMER/PFB/PGRAPH init) cycle.
After that success, benkai added save/restore of all PFIFO registers to the ioctl(). Nouveau now gets a PGRAPH context switch interrupt after X starts sending commands through the FIFO again. Unfortunately, the card emits weird errors afterwards.
As already noted in an earlier issue, find the current status here: http://nouveau.freedesktop.org/wiki/Suspend_support After seeing his power bill, Ahuillet expressed interest too.
And now for some information about the NV50. Originally we had hoped that the NV50 would have a NV40 compatibility mode, but that hopes were shattered early on. With reverse engineering being a bit behind and tasked to find his way around Gallium, Darktama decided to work on NV4x where most things needed were already known.
Concentrating on NV4x helped Nouveau do the impressive demos at LCA and FOSDEM but left NV50 in the cold. When Darktama changed his NV43 for a NV30 to help pmdata out with his init problems, he unfortunately broke his NV40. So faced with the option to work either on NV30 or NV50 he chose NV50 and tackled the 3D engine. After some hard work he found out that the 3D engine refuses to render to linear surfaces and the only way to make them tiled is to use some flags in the GPU page tables.
First thing he got working are buffer clears. Next thing he adapted was the DRM. A change there prevents GPU channels from directly accessing VRAM. They now go through the virtual memory system of the card. This is a necessary step towards supporting the tiled surfaces that are required for 3D.
Next thing is trying to get triangles to render. This however, needs some complicated changes in the Nouveau DRM. It is expected that the beginnings of Gallium support will come before EXA composite as we'll need to force all pix maps to be tiled, and dealing with software fallback cases could be tricky. Gallium is easier as there should be far fewer software fall backs. Rendering is always done to a private buffer (even when rendering to the "front buffer") and blitted to the real front buffer, it's hoped the NV50 2D engine is able to perform a blit from a tiled surface to an untiled surface. This is not yet known however.
Finally, a short assortment of topics:
- Marcheu has finished with his Gallium NV10 driver prototype an pushed it into the repository. Now it up to other to pick up from there.
- pq has posted his MMioTrace patch for kernel inclusion for review (Current 2.6.25 rc). Please help him by testing MMioTrace on your box, if you can.
- Some more causes of PPC lockups were found and fixed.
Since some time pq had some problems with AGP transfers (mainly ImageFromCpu). Those were identified and hopefully fixed.
- After the init problems on NV30 were finally solved, pmdata started to work on Gallium3D for NV30 and somewhat got scared by the shader stuff. He is considering moving to NV10.
- p0g starts to work on Gallium for Nouveau too
3. Help needed
As always: Look on our TestersWanted page.
pq needs your help with testing newest MMioTrace. Please do only apply if you are using a recent 2.6.25 rc kernel version. SMP testers are welcome too!
Stillunknown looks for NV5x testers to verify that his code clean up didn't break anything else. And if you could come up with MMioTraces of the blob switching to / from text console, that would be helpful too. Please ask pq, stillunknown or malc0 for advice.
I think we didn't mention it for the last issues, but we will happily accept additional developers. Please apply in case the current status for a certain card or feature annoys you 
And last but far from least: Please do test Randr1.2 with Nouveau. We will switch it to default soonish if no further problems crop up. Please remember: If you don't test, cute kittens will die!