The irregular Nouveau-Development companion
Issue for September, 28th
1. Intro
Ok back from my vacation and trying to recap four weeks of progress.
But before we begin some comments on the feedback I got regarding our move to Phoronix. To make it short: we raised the suspicion that we would sell out.
I am really flattered, I would have never expected that I would have readers who are so passionate about the TiNDC and where it is published first.
So why did we move? Basically to get the possiblity to address a wider audience and perhaps get some contributors from there. We are pragmatic here: Everything which may help the project move forward is worth a try and we are doing it not so much for us but for you. Not trying is loosing or giving up in our eyes.
Before we judge the usefulness of our actions why not give it a chance? Within the first 3 days we got 14.000 hits on phoronix.com and that was even before the article was mentioned on Linuxgames.com and digg. Whether that results in more contributors is still to be seen.
The coming issues won't have such a long delay between publishing on phoronix and publishing on the wiki, but due to time zones there will be a delay of at roughly 1 day.
Well, the time since our last TiNDC has seen AMD releasing their specs to the Open Source community. We are glad that our pals over at radeon are that lucky, hopefully NVidia will see the light someday too.
2. The current status
The end of August saw yet another move of parts of our services from personal accounts (in school, university etc) to fd.o. JussiP's status page and Marcheu's logger all moved to fd.o. And Kmeyer's script to update the dump directories from gmail was adapted accordingly).
With ahuillet's work on Xv done for the moment, developer attention shifted to other features.
First stillunknown who did port our device detection code in nouveau to libpciaccess. This library is Xorg 7.3 (xserver 1.4) new way of dealing with hardware accesses in a plattform independent way, addressing some of the major complaints about Xorg hardware detection. Later tests by Marcheu on NV04 showed it worked fine.
During the initial discussion of his plans with marcheu and Thunderbird, marcheu noted that he wanted to get rid of the PCI-ID list within nouveau. He intended to use only registers (like PMC_BOOT_0) for architecture detection and avoid anything which is targeted at a specific card and not an architecture. Stillunknown did as he was asked to and presented a patch which worked with PMC_BOOT_0 (on NV50 that is register offset $88000 instead).
Meanwhile pmdata and matc fought a hard battle against the Denial of Service that is glxgears on NV1x cards. During the last few issues quite a few problems were fixed (like invalid FIFO size, incorrect handling of PGRAPH interrupts) which slowly but steadily got glxgears "working" better. But still no output.
Trying some of NEHE's OpenGL lessons, pmdata noticed that the modelview and projection matrices were not handled correctly. p0g tried his luck on rendering a simple triangle. Therefore he used nv10_demo, checked a renouveau dump of his card and added all init data from the dump to the program. That caused some invalid state interrupts, so everything which caused an invalid state was in turn thrown out again.
Finally a triangle was rendered but only in very special circumstances (like certain window positions) and still the color was wrong. p0g investigated further and found that VIEWPORT_SCALE_[XYZ] values were not correctly calculated. He committed his changes to the demo where pmdata took up the ball again, trying his luck. After some minor corrections (resolution was fixed at 1280x1024), he finally found the error in his code: The color mask was set as a float while it should be an integer value. Again it was p0g who found yet another error: The sequence in which color and positional data was sent to the card was wrong.
So after much work, pmdata finally got this:
At this point, all that was missing was a proper depth buffer setup. A small hack for Mesa by p0g resulted in
and led pmdata to the "final" bug: The state buffer init for the depth buffer was incorrectly setup, after that was fixed, pmdata saw working glxgears too. We would like to thank p0g too, he did some very important support work, but somehow I couldn't find a topic to mention him in context - apologies 
But as we still do have some problems with clipping, resizing the window will give you strange results.
After some work on NV3x EXA marcheu switched over to NV04 drm issues. That nv30 work was to avoid running the blob before nouveau to be able to use the 3d engine.
Reason for the switch to NV04 was that ahuillet was expecting a NV04 card donation from a supporter of our project (Thanks!). But as DRM was broken by the "TTM" update (reserving a FIFO for the DRM), working context switching was needed. Some patches were already done by marcheu but lost in his hard disk crash mentioned in the last issue. So he set out to recreate them.
Also nv04_demo is now able to draw triangles on NV04
Trying to get NV04 working, Marcheu noticed some rare and hard to trigger corruption problems with Xv, which made ahuillet anxious to get his fingers on the NV04 which was sent to him by unbeliever (Thanks a lot!). First analysis led to the suspicion, that the blitter code on NV04 wasn't working correctly, probably due to (video) size limitations in the DMA code path.
When the CPU copy path was forced, everything worked "ok", that is, it flickered, but that was due to another problem. So there are some bugs left in the NV04 implementation of Xv but they can only be triggered by using really high resolution and thus are considered minor.
As a last note on Xv for today: NV04 overlay was implemented by ahuillet too.
On the G80 (not G84!) front, Darktama and maccam94 did some testing and found 2D to be working, although a few glitches remained (like missing parts of windows when refreshing or window moving stopping for a very short period).
Randr 1.2 was merged back into the master branch by Arlied which means that all available or worked on features are currently available through the master branch. To enable Randr1.2 for nouveau in master branch please use: Option "Randr12" "TRUE". Testing revealed that the Xv blitter was broken as was dual head.
Bk and stillunknown did some further work on randr12 and got it in a more workable state. That is, it should work on more cards than before.
Earlier versions of xserver did yield some compile errors due to newly added includes etc. but pmdata took on the task to fix them one by one. So nouveau should now work on xserver 1.1 too, but obviously without any randr1.2 support. So pmdata added / extended a configure option "--disable-nv30exa" which allows building and using nouveau on xserver >= 1.1
Stillunknown noticed some problems (e.g. missing prototypes for functions) and told Darktama about it. He took on the task to test it on his hardware and did kill of some warnings in the process.
More and more reports regarding randr1.2 support came in, most of them saying that it mostly worked. Most annoying thing is, that on analogue CRTs the output seems to be shifted to the right witha purple or pink border on the right side. Stillunknown is still somewhat pking in the dark, as he only has LCD screen (DFP) at his hands.
So he talked with Thunderbird and airlied about his problems and both helped him out with the information they had.
bk did some work on suspend & resume (from / to disk), trying to get a feeling for the needs of nouvueau. Situation is complicated by the fact that the kernel is currently missing some needed infrastructure to keep track of and be able to set modes.
After two days he got it working so far that no lockups occured and X found most of the important card context data. But still X crashed after resume with a DMA hang.
Some short topics:
- pq is now the official maintainer of MMioTrace. He already fixed some log writing bugs and has plans for additional module parameters.
- XAA support was finally removed.
- Fedora 8 now has up to date (well as of 20.09.2007) nouveau bits, thanks to airlied.
- Also thanks to airlied, most of the changes for TTM requested by our project are done.
- Marcheu and Darktama were at the X.org Developer Summit
- On PPC context switches with a NV17 are broken. Marcheu expressed interrest in fixing it. He thought that the breakage was due to notifiers moving out of VRAM to PCI space. A quick patch and a test later, PPC was working again.
One last topic: We are really trying to support all NVidia cards from Riva TNT (NV04) on. But during the last weeks we had to realize that we can't do EXA on NV04. It basically boils down to the fact that the NV04 can't do rectangle textures, only tiled textures, which don't fit well within EXA.
To accelerate EXA via 3D engine, we would need to combine / blend tiles which we don't have as EXA gives us a number of surfaces which are not tiled. NV04's 3D engine however expects tiled surfaces as source. We would have to tile the source surfaces on the fly which is a complex thing to do. To all NV04 users out there: We are really sorry.
BTW: "real" NV04s (Nvidia TNT 1) do not work with nouveau yet because they lack some methods that are to be implemented in software. Darktama wants to implement software methods for NV50, so ahuillet is waiting for him to push that to add NV04 support in nouveau.
3. Help needed
Please do test randr 1.2 modes and report back to stillunknown or bk
PPC issues should be reported to marcheu.
4. Thank you
In itself the TiNDC is not only a summary of the work done but a thank you to the dedicated work of our developers too. But this time we got some hardware donations for which we would like to say thank you:
This time a short thank you to evanfraser for supplying us with a few (real) quadro cards (NV3x). One of those is in the hand of Darktama already another one was "acquired" by our fearless project leader.
And thanks for supplying ahuillet with NV04, NV05, NV11 and NV15 cards. Thank you unbeliever and andreasn.
All developers are already slaving away and trying to add support for those cards