DE/EN/ES/FR/RU/Team |
The irregular Nouveau-Development companion
Issue for December, 14th
1. Intro
Well, I bet most of you did not expect me to show up shortly before the end of the year with yet another TiNDC. There has been some turmoil regarding my job. At first it was too much work followed by a somewhat unexpected folding of the company. So I had to find a new job, which is why I never turned up for quite some time.
PQ jumped in and did a splendid job on TiNDC #40 which gave me some headroom in digging through the pile of IRC logs. So this issue will mostly touch older topics and tries to stay clear of what was already covered by PQ. In the future I hope to write an issue at least once a month.
Much has happened: NVidia has announced new cards, released a bunch of beta drivers and a new final release. GForce 5 cards are now delegated to the legacy driver.
As always: Corrections, addtions and questions either on IRC or on the phoronix forums will be welcome.
2. The (Not So) Current status
Ok, much ground to cover. I will start to summarize events from June, 1st to October, 30th. The next issue will cover everything from November 1st up to the then current status.
Silverpower reported hard lockups from Nouveau. P0g investigated and found that the DRM detected a different arch than what the DDX used. He posted a patch which Silverpower tested, but which still caused lockups. P0g was a bit confused, because the DRM detected a different arch than what was used by the DDX.
Marcheu cleared up the confusion by giving an example: The DDX may use NV10 EXA on NV20 while using the NV20 context switching code.
Mjg59 and Malc0 were working on suspend / resume on a laptop. Mjg59 had problems in restoring the display to a working state. Some of the noticed problems were:
- 1x1 pixel display size detected
- backlight not turned on after a real suspend
- blooming
Faking a suspend / resume via echo -n test >/sys/power/disk, echo -n disk >/sys/power/state printed out seemingly correct values, though. http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-06-03.htm#1906 One reason - it turned out - was an old Nouveau version, which still had the old randr code as default.
Next came an mmiotrace of an NVidia blob suspend / resume cycle. The register writes were then compared to what Nouveau wrote. The result was: 32 registers were different, but why was still unknown. Further prodding from mjg59 revealed that there was a "...need to restore some of the ramdac and crtc registers in order to restore the correct screen associations...". Failing to do so let Nouveau detect a wrong output type (like a CRT instead of a laptop display).
Further hacking allowed mjg59 to get the backlight on, but still Nouveau wouldn't display anything else than a black screen. Of course, Nouveau claimed that it detected the display correctly and was using it. http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-06-11.htm#1230
More debugging and discussion ensued with mjg59 finally getting it right. Nouveau did not set PTIMER_NUMERATOR and PTIMER_DENOMINATOR. Setting those gave mjg59 a picture, that is, the display came up. However, still no output, no working text or graphics mode. http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-06-12.htm#1440
More testing showed a merge problem on mjg59's side which resulted in incorrect TMDS register writes. Correcting that allowed "nv" to get the card into a fully working state. (Yes, indeed "nv" not Nouveau. "nv" is sometimes a bit better getting a slightly messed up card into a working state).
Additionally, mjg59 later started working on generic thermal code into which driver like Nouveau would hook into. http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-09-30.htm#2053). A few days later and hwmon could read temperatures from NVidia cards through that code( http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-10-08.htm#2015), although it was a very rough first version.
Hanno had problems with his NV17 based computer, which prompted malc0 to offer him a patch (http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-08-07.htm#0321) which resulted in success. Marcheu was interested as to why the patch still was not in mainline, to which malc0 said that it contained some ugly hacks which needed refinement.
In came bkaindl and pestered malc0 about suspend to disk support for NV4x. Macl0 admitted having stopped working on it, as he had other things with higher priority on his to-do list. So bkaindl discussed possible solutions with malc0 while comparing the patch to the (then) current code for NV4x. When he spotted a difference he changed the code to work similar to the NV3x code path and was successful! However, testing the same changes with malc0's laptop did not work at all, which sent them both back to the drawing board.
Moondrake (our local PPC coder and tester) checked the patch with his Powerbook and it worked, too. Well, kind of, as he said:
- "malc0: your suspend stuff is amazing. [...] except for having to do hacks for doing the post in the DDX, remembering to setup bigendian mode and some panel hacks to turn on the backlight, the patches worked out of the box"
With this, one goal of writing an nv_bios kernel module to handle suspending NVidia cards was reached.
Besides the usual bug fixing, stillunknown started on coding a kernel mode setting driver for G8x. (http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-06-18.htm#2334) Having problems with a black screen, he turned to mmiotrace and found the problem. (http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-06-20.htm#1912). A few days later he committed his first version to mesa/drm/modesetting-101 (http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-06-22.htm#1703 ). Pq did some smaller code review and noticed a few memory leaks and typos which were promptly fixed by stillunknown. Further work, however, was put on hold due to the need of a proper memory management.
pmdata started his work on NV3x Gallium3D. He copied the NV4x code path and changed the state emission to work with data from objects instead of directly writing commands to the GPU. That work was finished about 2 weeks later (http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-07-12.htm#1319)
Darktama worked on NV50. Thanks to him the 2D part gained support for EXA composite and Xv. The support has some drawbacks, though:
- compositing manager is needed for Xv
- they should be working on most NV50 based cards. At least NV84 and NV86 should work, as well as the NV50 (= original 8800GTS). All cards having context stuff in the DRM should work. If not, let us know!
- by the way: EXA solid() and copy() were there from the beginning, as they are required by EXA.
Stillunknown and malc0 added some fixes for modesetting during this coding spree.
Marcheu finally solved the problem with the fixed pipelines for Gallium3D, but did not got to code it yet. P0g started with NV1x work got the gears to render and waited for Marcheu to start coding the solution. Marcheu suggested to do the fixed pipeline stuff as an LLVM optimization pass (LLVM is a feature in Gallium).
Randr1.2 code had problems when the EDID data channel of the LVDS (laptop panel) was wired but did not respond. That left the code without a screen resolution to work with. Stillunknown hunted through the BIOS in order to find out where the native resolution was exactly stored and came up with a fix a few days later (Bug report on http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-07-21.htm#2051 ). But it was not to be: Alphix still reported problems.
There has been some uncertainty whether GEM or TTM would be used by Nouveau. Well, we use both as GEM is not a complete memory manager, but an interface which needs to be implemented in the driver. As darktama put it on June, 5th:
- "I have (semi-complete) code somewhere for Nouveau drm/gallium on ttm, that's not stalled for any other reason than I want to get some g8x stuff sorted first since it could effect our mm requirements that said, I don't know which will prevail, I'm not really too concerned though.. there's plenty of hw issues/features to deal with first [...] Nouveau will probably use TTM [behind he GEM API]."
The various -ng branches are a playground for GEM interface with TTM behind the scenes (http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-09-11.htm#0947). They should mostly work, but with numerous bugs that need to be fixed, and some things that Darktama wants to rework. It is good enough to play with KMS on NV4x (malc0's code) and nv5x, and compiz works quite well on NV4x since DRI2 support appeared. (And no: We won't help you getting it to work just yet, you are on your own trying 
)
On the other hand, TTY restore for NV5x cards is still done via video BIOS (int 10) calls.
And as always, at the end a few (oh, well, a few more this time) quick notes:
- pmdata got NV30 dual head working
Matteo reported Nouveau working on a NV47 and Xv too. He was amazed (and we were not
) - A problem with text font corruption (glyph bitmaps were messed up) was reported and fixed within two days.
- Nouveau should now be available from the experimental Debian branch .
GatoLoko reported problems with fonts on NV5x and no YUV2 support on Xv adaptors. Darktama promised fixes which were committed about 24 hours later. GatoLoko tested it and confirmed that is was working correctly.
The TODO Wiki page was updated by marcheu (http://nouveau.freedesktop.org/wiki/ToDo)
- we have a new gallium-ng branch in git. This is highly experimental, hosting current memory management work. Please note: This is for developers only. It will work even less so than the unsupported gallium branch (we are speaking end users here!)
- moondrake did some code audits after he noticed some Xv overlay brokage. The culprit was a thinko when darktama reformatted the corresponding source file to be more readable / understandable.
- macl0 fixed an issue with "xrandr: cannot find crtc for output VGA-0" when trying to enable the second monitor. Bugs regarding laptop displays were reported but not fully resolved until October, 30th.
Marcheu is working on and off on LLVM for NV4 to NV20 cards with optimizations for NV30. That would allow Nouveau to translate shaders into fixed function stuff http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-10-10.htm#2139)
- Nouveau still has problems with interlaced modes on digital outputs.
- Ecco report a corruption on PPC64 which went away as soon as the old randr code path was activated.
- A few PPC bugs were reported and fixed.
Finally, we got some requests whether we would support OS's other than Linux. The answer still is: We will gladly take patches and give advice if possible. But all our main developers are on Linux and barely have any solid experience with e.g. *BSD.
It seems as if the DRM would need some serious attention on all BSDs in order to catch up with the Linux side of things. Nouveau will not work without and neither will any other modern DDX in the not too distant future.
3. Help needed
We would like to take the opportunity again and say thank you to all our contributors. That includes those who help out users in the channel, write code or documentation, as well as testers. Only all those combined make us move forward! But still, there are things where we could need help. Namely:
As we cannot expect Moondrake to do all PPC testing and bug fixing on his own, we would be grateful for PPC feedback.
Malc0:
- "anyone running a G70 (most gf7xxx) card at a high pixelclock (say 1920x1440 @ 85Hz); I'd love to hear from you"
We would like to thank okias for helping pq out with mmiotrace testing (which btw. finally got into mainline)
Oh, and what we currently don't need are MMioTrace or renouveau dumps. If that changes, we will announce it here! Exception to the rule are dumps and traces of the newest cards. Come into #nouveau on freenode and ask us, if you are unsure.