Back to our core project where we saw quite some progress too. Currently we are aiming for a working 2D driver (including EXA) for all models from NV04 to NV4x. Unfortunately NV5x is a different beast and may take more time. Still, until 05.10.2007 our master branch didn't work at all on NV5x / G8x but after some tests and bisecting done by KoalaBR, stillunknown found and fixed an error leading to a working 2D. Annoyingly, switching back to text mode leaves the display dead which makes testing the driver in case of errors hard.
On NV04 ahuillet fought an uphill battle to get X working. His first tries were met with ignorance from the card; the card simply didn't react at all. Just when ahuillet wanted to give up, matc showed him that he had made some faulty assumptions. Adding to that was a hardware problem with the mainboard, which resulted in random hardware init failures with both a NV04 and a NV11.
So ahuillet scrapped his code, restarted tried and finally got progress:
His software methods were called by the card, invalid commands generated the expected error interrupts. Next thing is the implementation of a few software methods. Software methods are commands that, when sent to the card, make the card ask the DRM to handle them. NV04 implements a few initialization related methods in software, maybe as a result of some design decision. Those methods merely set a flag in object instances, and are therefore not hard to write. When software methods need to be handled, the card generates a specific interrupt.
He got his code in his private git repository and expects it to be pushed to the master repository "soon" (next days). First, ahuillet needs to resolve one last issue, though X started but is slow as molasses as the card generates an interrupt storm of STATE_INVALID. It may have something to do with how we handle interrupts (there was a small change by ahuillet and darktama) but more like it is something else (maybe the state needs to be acknowledged). Investigation is proceeding. And before we forget: Overlay on NV04 works too.
pmdata tried to kill the rendering problems with glxgears with non default sized windows. Due to other work he had to stall that effort for now.
pq was trying to get NV20-demo working. He used MMio to get a trace and began analyzing it. To ease his debugging pains he started writing a mmio-trace replayer. This tool take a MMioTrace dump and replays it line by line. So you can see what register writes have what kind of effect. That and some trial and error reduced the log size from 60MB down to 4500 lines. That was no small feat because every replay of the traces needed a reboot. But as the card state survives even a cold boot for power offs shorter than 30 seconds, that endeavor took quite some time. In the end Marcheu remembered the reason while the problem occurred: There was no PGRAPH context init in the DRM at all, no one had written one yet.
After some testing he got initialization working and rendering of triangles too (within NV20_demo). Next step was getting glxgears working. As a quick hack, pq patched MESA to think that his NV28 was an NV1x card, which worked within the same limits as NV1x (more about that above and in the previous issue). The patch was never committed though as it is a hack and needs proper implementation in the driver.
However, init means correct per context init and that in turn needed larger structural changes in the DRM, breakage for all NV2x cards except NV28/NV25 was the result. At that time malc0_ offered his patch set to clean up init for NV2x quite a bit. This got all NV2x cards working again. Another result of all patches combined is that NV2x cards do context switching automatically and don't need manual interception anymore. You can find more info about NV2x context init here.
Work on NV20 proved to be difficult as pq always got a DMA queue hang very early in the X startup process.
When discussing his problems with marcheu, pq was asked to force notifiers not to be stored in AGP memory but in the memory of the card. That worked and proved that pq has some AGP problems: Notifiers placed in that memory region don't work (that is true for certain motherboards). (For an explanation of notifiers please refer to the last two TiNDCs).
Marcheu and JKolb did work hard to get NV3x working. First they tried to get NV30_demo working (that is rendering colored, bare and textured triangles). That proved difficult due to some init errors. After copying the init code 1:1 from nouveau it worked somewhat but crashed only after a few FIFO commands executed with INVALID_COMMAND.