[FrontPage] [TitleIndex] [WordIndex] 

Home

TiNDC 2007

TiNDC 2008

TiNDC 2009

Old Logs

Current Logs

DE/EN/ES/FR/RU/Team

The irregular Nouveau-Development companion

Issue for March, 19th

1. Intro

OK, I didn't make it to FOSDEM this year, still trying to work out health issues, sigh.

Well, we have some feedback from Marcheu later on and Phoronix.com did take some videos from several presentations. Unfortunately the sound the broken sometimes.

If everything goes well, we will have a short interview / status report on the FreeBSD port in the next issue. So if you have FreeBSD related question, post them in the Phoronix forums and we may pick up some good ones ;)

So let's start with the second longest TiNDC ever (BTW: PQ's TiNDC 41 ranks third).

2. The Current Status

OK, no more very old backlogs to read, back to our normal coverage.

Darktama did DRM-less work for Nouveau, which means that you can use Nouveau without the need of a DRM module in the Kernel. However, this will mean that Nouveau won't be able to do any acceleration, be prepared for very slow GFX operations then :) g2g591 did confirm that ab GForce 6150M was working without DRM module, slow(!) but fine.

Additionally Darktama reorganized our EXA code, killed some related bugs along the way and added support for newer Geforce 9 cards.

Nouveau will be default for 2D in Fedora 11, so the question whether and when we should do a release was decided outside of our project. However, with Darktama in charge of the Fedora effort (as we mentioned in the last issue, Darktama was hired by Red Hat), the release is in very capable hands. For more information about that topic, see the Fedora http://fedoraproject.org/wiki/Features/NouveauAsDefault.

Someone came into our channel and complained that his 260GTX card did not work with Nouveau, it only showed a blank screen and locked up the computer with a CPU usage of 100%. After obtaining some logs and traces, Darktama was able to produce a patch adding voodoo support for that card. Unfortunately, that proved to be not enough to get the card going.

pmdata and ymanton worked on the MipMap implementation which got broken after the swizzle update we mentioned last time. After some work and later fixes by ymanton Xmoto started to look like the real thing. See http://people.freedesktop.org/~marcheu/irclogs/nouveau-2009-02-03#1923 and http://people.freedesktop.org/~marcheu/irclogs/nouveau-2009-02-10#2146

After much work mjg59 finally got his back light code working. As we mentioned in earlier issues, several NVidia-based systems don't support back light control via the standard ACPI control mechanisms. Instead, the driver needs to modify the back light control registers directly.

After checking with malc0 and Darktama, mjg59 added some code to Nouveau (see http://mjg59.livejournal.com/107750.html http://people.freedesktop.org/~marcheu/irclogs/nouveau-2009-02-18#0041). After some configuration and kernel symbol problems, which were fixed by pq and mjg59 Moondrake tested the patch on PPC and it did mostly work.

His patch added support for determining whether the registers are used, and if so registers a kernel back light device to control them. The back light can then be controlled via existing user space tools.

MJules came in and complained bitterly about XV in Nouveau: Using the texture adapter for XV crashed X11. He was able to pinpoint the exact commit which broke it, but had two commits during which the breakage occurred. YManton found that XV forgot to unmap a buffer resulting in that crash. A patch later an MJules was happy again :)

Darktama pushed some changes which allocated an untiled scan-out buffer into which NV5x cards would render even allowing acceleration of the scan-out buffer instead of software fall backs. However, those patches were considered "hacks" by Marcheu, because wasted memory and performance for something the card should be able to do by itself. Problem is, that we currently don't know how to render to tiled (scan-out) buffers. Discussion ensued about what the patches were missing and what be a better strategy.

Some ideas were pushed around as to how to find out how those tiled buffers are setup. There seem to be a few places where we didn't look before (e.g we did look at the FIFOs but not at register access).

Stillunknown's version of this patch, with some additional fixes from Darktama is in the F11 fedora packages as they are a major performance improvement in a lot of cases. We know how to render to non-linear buffers, we can't use them for scan-out because we don't know how to configure the CRTCs for non-linear scan-out. Darktama spent spent some time looking at how to get it working, without success so far.

rdivacky came into our channel several times trying to get the big picture of Nouveau. Reason is that he is trying to find out how and if porting Nouveau to FreeBSD is possible. rnoland tried to do it earlier but noticed that this was way to much work for a one man team that he is on the *BSD regarding X. So rdivacky and rnoland agreed on working on it together.

So Rnoland started working on porting DRM, DDX and Mesa driver to FreeBSD. After digging into DRM and DDX code and asking questions about how things were expected to work, he started porting. Having some problems with how DRM maps memory resulting in invalid handles and fixing those, DDX and DRM started working fine for NV4x based cards. In case you don't believe us, here is a screenshot of a 6800GT in action on FreeBSD:

FreeBSD-Nouveau_small.png RNoland proudly presents: Gnome using Nouveau on FreeBSD

NV5x is still out of reach as it's architecture and thus the code is vastly different from NV4x. It currently is unable to map the GART so anything beyond basic TWM start up locks the computer reliably. Patches are currently coming into our repositories, but we are not able to give you any instructions on how to get it to work there (Hint: Our Wiki allows for adding pages YOU write).

Side note: If you are an ATI user on FreeBSD fear not, as r6/7xx DRM is in -STABLE now. (That's all we can say, for more information you should pester the TiRDC guys)

Stillunknown is reverse engineering the texture layout on NV5x and later GPUs because he wants to be able to do software rendering to tiled memory. The problem is that DRI2 requires pixmaps which are backed by buffer objects. In order to do that you change to a different type of EXA for which the current hack^Wsolution is very slow (about 50-100 times from what it could be).

So it seemed like a good time to actually find out how textures really look like on NV50. This more work intensive way was chosen because it will serve us better in the long run (less hacks...).

Trapezoids, triangles and polygons suffer, because they rely on *a lot* of CPU access. Simply put, this is what is happening:

which costs CPU cycles without yielding any benefit. If that works out OK, we will be able to start accelerating those calls, but this for a next step.

On NV9x chips the hunt is on to find out what strange things are happening there regarding texture layout.

And as usual or short news:

3. Bonus: FOSDEM Coverage

Well, it was that time of the year again, and once again I have rely on others to give me information of what happened.

Marcheu did two talks this year: About the state of Nouveau and about Gallium and its LLVM usage.

And here are our questions to Marcheu:

2d status

Q: It seems to work fine as is, I rarely see serious problem reports anymore. What is your point of view?

Yes, our 2D accel is mostly stable, and has seen nice performance improvements recently with EXA core changes. Hopefully that code will require less attention over time, and we can focus on the 3D bits instead. However, EXA changes are still required on NV50...

Q: What is barring us from finally releasing a 2D only driver?

As always, the kernel interfaces. If we merge our DRM into the kernel with [an] unfinished interface, we will have to maintain them forever. In order to ease our burden later on, we will only merge when we are happy with these interfaces. So, merging our DRM into the kernel requires:

Q: So what about Kernel Mode Setting?

Hmm, you already talked about it above, what should I add to this? :) But we can say that it's starting to work on NV50 cards, and that the NV04->NV40 Randr 1.2 code should be pretty straightforward to port to the kernel. The point of concern lies in the bios parser though, which remains incomplete as of today.

Q: Is VT Switching finally fixed?

It should work, it's only temporary breakages that just happened the last couple of months :)

Q: Recently back light support for some NVidia cards were added by Matthew Garrett and I seem to remember he is working on some kind of suspend / hibernation too?

Matthew is working on power management for all cards. So he splits his time between different graphics hardware, it's not Nouveau-only :)

As far as suspend/resume goes, we need to be able to execute the BIOS script language to resume a card (the same one that's unfinished for mode setting). Stuart is currently working on this, and cards up to and including NV40 should suspend/resume mostly once we enable it (testers are welcome of course, as this is a touchy issue). For NV50 we lack someone working on this, so these cards don't make it out of suspend...

Answer from Matthew Garret:
As far as suspend/hibernate support goes, there's two main types of problem. The first is that on resume from RAM the card is usually completely uninitialised. Reinitialising the card can be achieved by either executing code from the legacy video BIOS in an x86 emulator or by executing the NVidia BIOS tables in an interpreter. The first doesn't work on most NVidia cards - after the initial POST the bios rewrites itself so the entry point simply exits. The second is achievable on pre-g80 cards, but has not been made stable yet. Simply executing the scripts is insufficient, as some register state needs to be saved and restored across the suspend/resume in order to allow the scripts to run properly. The scripts have not been sufficiently reverse engineered on g80 and later hardware to be able to work on this.

The second suspend-related problem is restoring the state of the acceleration hardware. Reinitialising the card is adequate for unaccelerated 2D operation (as provided by the "nv" driver), but if the acceleration state is not restored then switching back to X may cause the X driver and card to have inconsistent ideas of the world. At that point, the system may crash.

I've done some work on reinitialising the cards on pre-g80 hardware, though it only seems to work on my machine so far. I've done nothing on the acceleration restoration side of things.

3d Status

Well probably that what most of our readers are interested in.

Q: Last year NV4x cards were the ones supported best in terms of 3d. Does this still hold true?

Yes, although NV30 comes as a close second now, as both can mostly run OpenArena.

Q: What about NV5x and later cards? A bunch of patches came into git since Ben got hired by Red Hat...

It just does the basic stuff for now, i.e. no Quake 3 :) By the way, if you're interested in joining, improving the NV50 driver is probably one of the most feasible tasks at hand right now (Please see our SoC request in the Help section too)

Q: From reading the logs, it seems that one of the last big hurdles is the tiled scan-out buffer...

Hopefully, but I don't think you can ever say "last hurdle" in that kind of project :)

Gallium and LLVM

Q: Could you give a short overview about the current status of Gallium in general? Are the APIs stable?

Ongoing development is happening in the field of texture transfers. Basically these new abstractions will allow more efficient transfers of texture and pixel data to and from texture memory. In order to do so, two main changes were done by the Vmware people (formerly Tungsten Graphics people):

Other than that, the APIs have not changed recently.

Q: So what about LLVM, why did we need it at all?

Currently, Gallium3D generates shaders and sends them to the card without optimization. As shaders are used everywhere, this results in suboptimal performance. On the other hand, LLVM is a compiling a optimizing framework that's aimed at being retargetable and flexible.

The plan with LLVM is to have it optimize and compile the shaders for the Nouveau-supported cards at least. For this, we need to have Gallium3D output shaders to LLVM. Then, we have to write LLVM backends for the cards we want to support.

Q: And what is the current status?

The current status is that we're able to run some vertex shaders on the CPU with SSE code generation (using the git gallium code). Using LLVM and some basic tests it's also possible to detect fixed pipe shaders, and we also have the (unfinished, really) hardware description for NV40 chips. But all this is still in independent programs at the early stages, the code needs to be plugged back into the right places.

Outlook

Q: As we missed our initial goal for the first working 3D Nouveau slightly (*Ahem*), what are your current thoughts about our schedule?

I don't think we should make schedules, we've proved before that we aren't good at it :)

Q: Where are your slides?

http://icps.u-strasbg.fr/~marchesin/nvdri/nouveau_update.pdf
http://icps.u-strasbg.fr/~marchesin/nvdri/g3dllvm.pdf

I would really like to thank Marcheu for taking time to answer those questions although he currently is very busy in Real Life (TM). Same for Matthew Garrett who took the time to answer my questions although he was in the middle another project / problem!

4. Help needed

Summer of Code is once again coming this year (albeit a bit smaller) and we need suggestions. So if you have ideas or even want to participate, please contact us before April 3rd. If you read this issue, you should a have a few basic ideas of what needs to be done ;)

Darktama is asking for tester of 9xxx cards, which until yet didn't work (see last issue, too). Please let us know if 2d works for you now. We had one report that a 9600 M GT is working, but we would like to have more feedback.

So *BSD fans, here is your chance to help Nouveau on your platform: RNoland has currently a 8800GTS and a 6800GT both PCI-Express. To allow for a wider range of cards and bus systems to test on, he would gladly accept any donation of a NVidia AGP card ( >= NV1x).

Finally two requests by malc0:

<<< Previous Issue | Next Issue >>>

2013-03-24 13:16