The irregular Nouveau-Development companion
Issue for February, 15th
There are times, when you think you did absolutely understood what was explain to you in IRC, write it down and by doing so, you proof that you totally misunderstood. That's what happened to me for the last TiNDC issue. Embarrasing, that it happened twice ...
But doener helped me out and corrected my mistakes, thank's a lot! So if I do mistakes, either contact me and ask for correction or do it yourself, it's a wiki you know :)
And for all of you, who are wondering why we are developing this and why we don't use certain tools, let me cite Marcheu :
|See... indent is the path to the dark side. indent leads to automake.|
|automake leads to anger. anger leads to hate hate leads to binary drivers|
|and binary drivers lead to dead kittens !|
Mandriva now includes rpms for renouveau in their distribution. So for all of you Mandriva users, have a look at the available rpms.
Fedora has added our driver to their setup too. It is not default, though, due to reasons explained in an earlier issue.
And it seems that we may gain some support from the Ubuntu camp: http://www.markshuttleworth.com/archives/95
Now the last weeks were a bit slow going. This is partly due to four things:
- We need a memory manager, currently in final stages of development, called TTM. However it needs "fencing" to be useful for us, a feature currently missing. Seems that as of 15.02.2007 the new TTM has been merged to mainline drm.
- marcheu is short on time (managing a part of FOSDEM)
- darktama is in the tinkering / research phase
- pmdata is still chasing crash problems on his NV1x card.
Just shortly after the last issue, Airlied published a screen shot of glxgears running "perfectly" on his G5 PPC Mac. Look here: [[!img http://www.skynet.ie/~airlied/pics/gears_ppc.png]
Although the gears do move, there is obviously some more work to do.
After getting more and more reports that glxgears was broken on some NV4x Darktama used a major update for NV40 software fallbacks to correct some errors. After that, testing showed that NV4x was working again. It seems that a small bug in previously unused code in nv10swtcl (software transform, clipping and lighting) prevented the driver from working. More work on this front revealed, that under certain circumstances the fifo switch could go wrong (leading to crashes). A hack to avoid this was implemented by Darktama but he is still looking for a more elegant solution. Testing revealed however that this patch wasn't enough, it still lead to crashes, some with very interesting symptoms.
But Marcheu had some patches pending. On February 13th, marcheu pushed this patches into the repositories. Trying out those patches, KoalaBR found out, that the problems noted above on NV4x were nearly gone and thus stability was much improved, but it was still possible to crash the driver. Darktama jumped in with a debug patch with was applied and the resulting Mega Log File (TM) is currently waiting for evaluation.
Regarding the spotlight parameters, jwstolk is quite sure to have found the correct formulae for setting up the cards. Remember that we have three parameters in OpenGL (spotlight cutoff, exponent and direction vector) which are then spread out to 7 different values which in turn get written to registers on the graphic card. However, how those 7 values were derived from the OpenGL parameters was unknown until jwstolk finished his work.
|(many different combinations of exponent and cutoff) it works :).|
|I'm not sure how it behaves at corner cases like exponent=0 or cutoff=90|
One problem less to care about, thanks to jwstolk!
After pq settled on a nearly complete design for the rules-ng.xml, he was offered help from KoalaBR in designing a XSD (XML Schema) for his design instead of a DTD. Currently 90% of the XSD is done (only missing some doc tags) and it is syntactically correct but it still needs verification (try to verify a given rules-ng.xml file against the XSD. Much thought has gone into the design from pq and so creating the XSD was quickly done. Testing it with xmllint / libxml2 though yielded interesting error messages and more work is needed. That was when Wallbraker offered his help and used Eclipse for validation. Some more refinement for the XSD took place but it is too early to judge the results yet.
Last but not least, aeichner did some work on mmio to avoid the need for a kernel patch. He is still looking for testers but some restrictions may apply, but see the current info on our MmioTrace page, quite a bunch of restriction have been nullified during the last days.
If you still encounter 2D crashes, please report to Marcheu or KoalaBR. It would be interesting to get an mmio-trace from a GeForce 8000 -series card, you can contact PekkaPaalanen for that, although he will not be the one doing development for that card.
<<< Previous Issue | Next Issue >>>