[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 January, 21st

1. Intro

Happy New Year to all of you, thanks for reading our companion once again.

Well, once again destiny decided to put work on the TiNDC on a back burner, a bad flu followed by a lumbago tied me nearly 2 weeks to the bed. So let's not waste anymore time in getting to the meat of the TiNDC, the (still not so) current status.

The last issue stopped monitoring the logs on October, 30th so what has happened in November and December?

An important news first: Darktama was hired by Red Hat Australia, moved to Brisbane and started working full time on X.Org and Nouveau. Congratulations to him!

And as always: Thanks to my reviewers of the TiNDC who once again took on the task to let me look much more competent than I am. PQ and Darktama fixed the most glaring bug in this draft.

2. The (Still Not So) Current status

Tronic reported a hang in Nouveau for an original 8800 card. The first ones were slightly different from later cards (like e.g. 8600GT). Every code supporting those first generation NV5x cards with Nouveau was deduced from MMioTraces. After getting Kernel and X logs Darktama found that it was indeed the acceleration code and did buy a card on EBay. The bug was then promptly fixed, the 8600GTS is now in darktama's primary desktop.

PQ started working on NV20 Gallium code. First thing getting to work was glxinfo. Rendering a simple triangle however proved harder as vertex buffers were not yet implemented. Additionally, resizing the rendering window caused an assertion. Further investigation suggested the idea that handling clip rectangles in Nouveau was broken, giving out uninitialized structs. A few days later he still had problems to understand the code fully, as he was missing how Gallium attributes (e.g. Pos and Color) were sent to the FIFO. Marcheu told him that currently there was no assignment. We just copy those attributes to the FIFO and the same sequence we get them handed down through Gallium. After much trial and error (plus additional feedback from p0g and marcheu) pq finally managed to get NV20 to render a simple triangle: However, this code was emitting and using NV10 objects. When in early December everything pq converted all objects to NV20 objects and is fighting since then to get everything working again, but the card does not report any errors.

Marcheu is still working on the LLVM back-end. LLVM is a compiler frame work which takes shader op codes, generates an internal representation from it, does optimization for it and hands it finally out to the hardware specific back-end. Normally that would be x86, PPC etc. code but in case of Gallium the code is turned into shader code for NVidia cards (there is another back end in development by Corbin Simpson, which works for AMD/ ATI cards). Currently he is working on NV4x shaders, but adding additional should be a no brainer once everything is in place. Much more information about the current status will told at FOSDEM, as Marcheu holds two talks (about Nouveau and LLVM) there.

One of those things in place was the merge from our repos with the gallium master repos. After some discussion with Darktama, Marcheu finally merged our code with master mid November.

RNoland came into our channel and asked for help in getting Nouveau ported to *BSD. After some introductionary info from stillunknown he started off to get it working. First question was how we managed PCI-IDs, as he was looking for some kind of list or "database" of valid Ids in the driver.

PQ and Stillunknown told him that we don't use the device ID at all. Instead, we ask for all PCI devices that report themselves with NVidia vendor ID, and a graphics card class. To identify the chip set, we read register 0 (NV_PMC_BOOT_0) and find out what chip set (as in NV34, NV50, NV50 etc) the card is from there.

Some words about the current plans for Nouveau: There is one major roadblock which needs to be cleared in order to be able to release at least a "Nouveau 2D" version of our driver. This roadblock is called Kernel Mode Setting (KMS).

With an Intel version going into the vanilla kernel, the API for KMS should be mostly stable. Still, every driver using this would need a memory manager. We basically settled for a TTM with a GEM boilerplate, but only our NV50 code uses this and that part of the code is far from being finalized. So the bitter truth is: We currently are working towards getting a memory manager, but it is not there yet. Correction: That is no longer correct, since all of our code paths from NV05 to NV5x in the ng-branch are using TTM with GEM.

Additionally, we do have some NV50 and NV40 KMS code which is a prototype. It works under clearly defined circumstances but is not ready for general consumption. Work on it should be resumed soon or is already under way.

As you can see: There is still much to do until we can reach the first release milestone.

We did have a few requests regarding 8200/8300 and some 9400 (there are also normal 9400). Those chips are onboard and currently have problems with Nouveau (or vice versa, pick your poison :o) ). A missing voodoo for those are only the first problem. As even nv doesn't work with those chips yet, we don't even have a hint of what to do.

And finally a few quick notes:

3. Help needed

Not directly related to Nouveau but pq is looking for someone to take over MMioTrace maintainership midterm. If you are interested, please come into #nouveau and ask pq!

FOSDEM is early next month. Not sure if I will be attending, but in any case I am trying to put together yet another special edition. This is a must as there is traditionally a "State of Nouveau" talk by Marcheu. Hope to see you there.

<<< Previous Issue | Next Issue >>>

2013-03-24 13:16