Nouveau Companion 32

Thunderbird used data supplied by willing testers in our channel to create a clock speed calculator / generator. It creates valid memory and GPU speed pairs within the bounds allowed by the BIOS. So we could later hopefully over-clock NVidia cards via nouveau without the fear to harm the card. Underclocking is not a problem. Over-clocking is still a problem for cards that start up at a lower voltage. We currently don't know how to program that, and from what Thunderbird says it's *very* card-specific.

A comparison between the clocks the blob generates and Thunderbird's version showed some differences for corner cases but in most cases calculated exactly the same values as were set by the blob. But because Thunderbird doesn't want to risk hardware through wrongly computed values, he is still enhancing his code and thus, it isn't released yet.

During the last issues we often referred to Darktama's work on Gallium3D for NV4x and NV5x although we noted that this work isn't published yet. Well, it is now but before you faint because there is finally a free 3D capable driver for NVidia just one advice: Calm down :) Although much works, even more does not (both on our and on Gallium's end), isn't implemented or is buggy. In addition, it isn't fast (compared to the blob) but still, it's faster than software. Currently we don't have any install documentation for that, so you are on your own. Well, seems as if Darktama has found a culprit in our code. He is sure to increase performance, but isn't finished implementing and testing the fix.

Just a few examples of what to expect:

Google Earth:

Quake 3:

This one is an impossible screen shot of Quake 3 Arena (demo). According to darktama, the code should have hit an assertion (he did try it on his development system) with an immediate exit of the program, but AndrewR's system obviously made it through somehow.

The official Nouveau repository can be found here. Darktama is doing his own git repo, which is his playground, and it tracks the official Gallium nearly "immediately". As Gallium itself is evolving that means the code may or may not work. Reasons may (or may not) be bugs in Gallium or buggy / not yet implemented features on our side. Sometimes Darktama is even fixing bugs in Gallium itself...

Some short topics:

- ahuillet has had a look at NV2x mode-setting. He did some tests and traces for Malc0 and stillunknown. He is still undecided on whether to do some work there or to wait for Marcheu and his Gallium3D framework.
- pmdata finally got NV30 to work with EXA. A strange nv30tcl command 0x2b8 has view-port x,y values and was needed for nv30exa to work on nv30gl but was missing until pmdata fixed it.
- We just noticed that JussiP's script is looking for the dumps in the wrong directory, which no longer gets updates and thus is very outdated. We'll try to update his script and report from the correct download directory. None of the dumps sent were lost though!
- stillunknown is considering implementing TexturedVideo via shaders for NV4x. That would further enhance our not too shabby Xv implementation.
- jb17some is still working on XvMC and is slowly making progress. He has some more information about how Luma (Black and white data) and Chroma (color data) is stored.
- Marcheu is still working on separating Xv code into a card independent and dependent part.
- p0g reported EXA breakage on NV1x but working RandR 1.2 with one monitor. The breakage was due to stillunknown's rotation work, which clashed with ahuillet's A8+A8 patch (feature wise, not on source code level). It is now fixed.

Help Needed

Stillunknown and malc0 are looking for testers of their RandR 1.2 related code and tools (for data extraction and comparison).

As always, please have a look at the Testers Wanted page for requirements coming up between our issues.