The irregular Nouveau-Development companion
Issue for January, 30th
1. Intro
And here we are again: Issue number 34 is here for your reading pleasure. Thank you very much in your continued interest in our driver and TiNDC.
Just as an example how important testing is for us, during the last 14 days both rindolf and AndrewR reported regressions. Rindolf had problems with jitters after extended periods of time in X while AndrewR got a kernel panic. Both problems were introduced about one week before they were reported, which made searching for the bad patch quite easy.
So, even if there are no bug fixes or new features announced for your card, please do test at least once in a week to make sure everything keeps working.
During the last weeks the discussion came up, whether we should work on getting a 2D only release finally out of the door. There were proponents for and against it arguments were exchanged and a decision postponed :).
Pro arguments:
- Distros could start shipping us without much hassle
- It would get us more testers and users.
- It would show that we are really progressing at a good pace and that we are a successful (in regards to for end users graspable results)
- Better get a release out of the door before we offer 3D for real. 3D will get us a huge influx of testers and users and in combination with 2D may just overwhelm us.
- release early, release often
Contra arguments:
- NV5x support is very much not there
- We don't want to support a stable DRM interface just yet (which would be needed for distro integration) as at least 2 more changes will be needed (for mode setting and TTM)
RandR1.2 isn't good enough yet.
- No need for a huge amount of additional testers and users, we need dedicated testers which are interested in solving specific problems, as we currently have.
As each sides had valid points, no final decision was found. So we decided to wait a few weeks longer and discuss our options at FOSDEM next month.
And for the record: No we were not approached by Nvidia regarding specs (And to be honest we don't expect them to contact us).
2. The Current status
It seems MMioTrace will stay broken for kernel 2.6.24 as the relevant kernel hacker doesn't intend to bring the hooks back. The good news however is, that pq is starting to work on integrating MMioTrace into mainstream kernel and does get support by said kernel hacker in order to find similar functionality to that which was removed. There is a consensus that MMioTrace is a worthy tool for mainstream kernel.
If everything works out ok, we will see MMioTrace in a working state from 2.6.25 or 2.6.26 on.
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 tesselation 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. (http://gitweb.freedesktop.org/?p=nouveau/xf86-video-nouveau.git;a=commit;h=d9149bddc758cc0644630b26fe10fc563ba38ce9)
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. http://gitweb.freedesktop.org/?p=nouveau/xf86-video-nouveau.git;a=commit;h=71435dde5b2fd1c197ef5dc31b22ba40abcbca7e
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. So 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 here http://nouveau.freedesktop.org/wiki/Load_Detection
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:
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.
And 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).
3. 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.