The irregular Nouveau-Development companion
Issue for December, 24th
1. Intro
With the year 2006 now coming to an end it is time for one last issue before I will pickup the work again in 2007. Take it as a christmas gift for you poor blob users.
Shortly after I joined the project in August, marcheu stated, that he was aiming for displaying triangles in time for either FOSS or Linux Conf Autralia. With darktama's latest work, we have reached that goal at least for NV40+ cards.
In the last issue, I talked about adding a section "In the Press" to the TiNDC if this should become necessary. Well, with one issue every ~ 14 days I'm too slow it seems. pq already added a page to our wiki for that. Nevertheless, please let us know if you find anything outside of developer sources which talks about our project.
For those new to our project: If you are just an end user without any idea of X11 setup / configuration, please ignore us, we are far away from a useful state (for you). We still aim for a mostly usable driver for autumn 2007.
If you don't mind crashes both hard and soft (if testing 3D, 2D should be stable, but see "Help needed", too), if you want to test the robustness of your journalling file system, then please come forward, nouveau is exactly what you are looking for. It should work (well, see above...) on 64Bit, x86 and PPC.
And one more remark: Nouveau is much more than the persons which get mentioned here quite often. Everyone coming to our channels and offering help counts. It shows that there is an interest in our work and every single bit of help moves us further along to our final goal: A working free driver. Thank you very much for your support and a Happy New Year to all of you!
2. Current status
pmdata, pq and company fought the perils of the spotlight variables. We currently think that we know all source variables, but the target variables (which data is written to which part of the card to trigger the wanted feature) are only partly known. According to pq: "spotlight originally had 7 unknown target variables, of those we now assume to know 4. Source variables are spotlight cutoff angle, exponent, direction... hopefully not too many others." The calculation of the cutoff angle was found out this week. For more info on the exact nature of the parameters, please follow this link: http://nouveau.cvs.sourceforge.net/nouveau/doc/nv20_light?revision=1.2&view=markup
So back to our regular report on the status of glxgears: When we left our programming hero darktama last time, he had fought the perils of double buffering, the daemons of clearing and was clashing heavily with the dragon of depth buffering. Well, he was victorious.
You can see the full size screenshot. Please note, that double buffering is working now, it honors the screen coordinates and doesn't copy everything back to Pos (0,0).
Now, after some time there is work done on renouveau again. This effort is lead by marcheu and was kicked off, when creideiki offered dumps of his 8800 card. After hard crashes and segfaults he finally got his dumps for us: 1GB compressed. Of course this couldn't be correct (even the 8800 has "only" 880MB, if my memory serves me right), so marcheu started looking into the problems. Fixing some problems and verifying some patches (thanks for your persistance creideiki) things started looking better though still not correct until now.
airlied did good on his promise to add nouveau to Mesa git once everything for Mesa and us was sorted out. So on 19.12 / 20.12 airlied took the time to import both our drm and nouveau into the Mesa git repository. He took great care to keep our history intact. Thanks you, airlied!
That said, please note that the instructions on page "InstallNouveau" are currently not up to date. I will try to redo them ASAP by doing everything step by step again.
Well, reverse engineering showed that commands and objects for NV10/NV11, NV15 and NV17 are the same. Nevertheless, our generator for nouveau_reg.h wrote them back 3 times into that file: Once for NV10 / NV11, NV15 and NV17. After some guidance from marcheu, that problem was corrected by KoalaBR. The solution is generic though, so that we can extend that to other cards too, should the need arise.
sectroyer offered to save our Required Feature page from certain death and started to update it slightly. Hopefully this page will change into more of a "Implemented Features" page.
3. Help needed
Currently, the 2D driver seems to be mostly stable with two notable exceptions:
- G80 (8800 cards) don't produce any output when using nouveau
- GF7x00 users often report crashes, but we don't have a clear picture which cards are affected. So if you are living on the bleeding edge by using nouveau with a 7x00 card, let us know whether it works for you or not. Please report the PCI id (lspci -v) too.
Some people offered help with SLI dumps, but we are still looking for more input. So please drop into #nouveau on freenode and offer your help.
4. Off topic
To be honest, I really wanted to mention this, but it doesn't really fit into any of the sections normally available. So as an exception to the rule: The "Off topic" section.
During the last ~ 2 weeks there was quite an argument on the Linux Kernel Mailing List, whether the Kernel should allow the loading of binary driver (like the well know Nvidia driver). Greg KH thinks that binary only drivers are violating his copyright as a kernel developer and wanted to prevent loading of "Non-GPL"-Modules.
However during the discussion, Linus pointed out, that the proposed patch would deny normal users to do whatever they wanted with the kernel (as long as the result was not distributed!) and that he would personally oppose such a move.
Greg admitted that his patch was over the top but voiced frustration about the fact that he couldn't do anything against binary blobs. At that point Alan Cox suggested:
"...Another thing we should do more is aggressively merge prototype open
drivers for binary only hardware - lets get Nouveau's DRM bits into the
kernel ASAP for example."
This suggestion was supported by Jeff Garzik. (http://www.uwsg.iu.edu/hypermail/linux/kernel/0612.1/2070.html)
On which David Airlie (Airlied) replied on our behalf:
"It'll get in when the developers feel it is at a stage where it can be
supported, at the moment (I'm not speaking for all the nouveau team
only my own opinion) the API isn't stable and putting it into the
kernel only means we've declared the API supportable, I know in theory
marking it EXPERIMENTAL might work, in practice it will just cause us
headaches at this stage, there isn't enough knowledgeable developers
working on it both support users and continue development at a decent
rate, so mainly ppl are concentrating on development until it can at
least play Q3, and for me dualhead on my G5 :-)"
(http://www.uwsg.iu.edu/hypermail/linux/kernel/0612.1/2217.html)
However, this shows that our project was at least noticed by the kernel developers and that we will have some supporters when we reach a point where we want to move parts of nouveau into the kernel.