Nouveau Companion 34

Stillunknown pushed an experimental restore system for mode setting which can be enabled by "NewRestore" with value "true". AndrewR didn't hesitate and tested it immediately giving feedback to stillunknown. Feedback was mixed, for some it worked, for some it didn't. Stillunknown reacted by adding at least two fixes over time to his code.

Artifacts with the texture adapter

Still not tired of adding features to Nouveau, stillunknown did some tests with the texture adapter and noticed artifacts and tearing on his card. After talks with Marcheu and Ahuillet plus further tests, he discovered that the blob renders 2D large quads (larger than roughly 512x512 pixels) by rendering a triangle as big as needed to include the quad then using scissors to reduce rendering to the desired quad. This has the effect of doing top-to-bottom rendering (as opposed to two-triangle tessellation that takes place when you ask the card to draw a quad directly), which suppresses tearing. He implemented this strategy for the NV40 texture adapter and rendering was fine (git commit).

Fixed rendering

Thinking more about this issue he came up with the idea to apply this to NV40 EXA too. It worked out great and should eliminate tearing in EXA, although I didn't notice anyone complaining (git commit).

After the holiday break some of our previous testers returned and gave an update on their status. chownmeined reported that both normal and RandR1.2 code was working perfectly. seventhguardian reported a regression when starting X: The screen remained black. Stillunknown found the bug and committed a fix which worked for seventhguardian. Darktama still has problems with his Laptop and Nouveau. The screen stays black. Some fixes applied by Malc0 at least got the backlight working but still the screen stayed black. Therefore, a debugging session was in order which gave malc0 additional data points to think about. A solution is still pending.

Additionally, Malc0 enhanced the BIOS parser for NV4x cards, as those BIOSes could exhibit opcode not yet handled by our parser.

SeventhGuardian did some work on TV-OUT detection after talking with Thunderbird, malc0 and stillunknown. First tries resulted in randomly detecting TV-OUT but he kept trying and finally found out, which registers had to be set how and what was returned by the card. So we now have a working load detection. A "load" in this case is a connected output line like VGA, TV-OUT, DVI etc. He summarized his findings in our Wiki.

SeventhGuardian intends to start working on TV-OUT now.

And now to our regular assortment of short topics:
- Marcheu has implemented bi-cubic filtering for the NV40 texture adapter killing of all known artifacts. The code isn't merged but should be real soon now (TM).
- Marcheu will port this code to the NV30 next. This experience is needed to finish the Gallium 3D framework for older cards. And then finally 3D acceleration work for older cards can start.
- After a few days of hacking, pq managed to get MMioTrace working on kernel 2.6.24.rc7. So he is on a good way to send his module for inclusion to LKML. Although there is still work to do, feedback from the list to be taken into account etc.
- Darktama has adopted a new IRC strategy: Keep quiet, don't move. And in case someone has a problem with the driver, just drop a line how to fix the problem (even if it is not on NV5x or NV4x) and switch to quiet mode once again (happened at least twice :))
- Darktama noticed some problems on NV4x and how we manage contexts there. He has a suspicion how to fix it, but needs more NV4x MMioTraces.
- The problems we had with viewport setup on NV30 cards were fixed at first by pmdata, but his solution broke other NV3x based cards. It seems that Stillunknown found the culprit and fixed it (git commit).

We had some complains coming in that dithering on flat panel displays were bad (hughsie, egn and tango_). Malc0 said that Nouveau writes the same values to the dithering registers as NV and not as the blob. He suspected that NV uses default (safe) values while the blob writes values fitting for the card type. Quick tests done by hughsie and tango via radeontool (nvidia branch) with the blob's values did confirm this suspicion. While it worked for hughsie it didn't for tango.

Radeontool is another tool to read out MMIO registers. It was originally developed for radeon but has a branch for NVidia cards too.

We did get some reports that NV1x was extremely slow in 2D rendering. This seems like a regression and we are currently trying to find out, what exactly caused it.

Finally a little bit more about the status of our Gallium code. As was said before, darktama is working on it for NV4x. It works mostly but has some hackish code which prevents it from working correctly in all situations. A fix to that will take some time. The good news however is that the Nouveau 3D is much faster than the software version (softpipe).

Help Needed

As always:
- Look on our TestersWanted page.
- Check for regressions in the RandR1.2 code.

Additionally:
- Send in MMioTraces for NV4x cards (which would be 6x00 and 7x00 cards). And if you do, please run a 3D app of your liking (please say which in your mail), at least glxgears.
- We are looking for RandR1.2 testers, especially for NV04. Please do test and report back to Malc0.

As the RandR1.2 code changes often, do test often. Do point out regressions to malc0 and stillunknown too, if you find some.