Nouveau Companion 43

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 and 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 fallbacks. 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 do not 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 did not 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 many cases. We know how to render to non-linear buffers, we cannot use them for scan-out because we do not know how to configure the CRTCs for non-linear scan-out. Darktama 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.

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 do not believe us, here is a screenshot of a 6800GT in action on FreeBSD:

NV5x is still out of reach as its 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 is 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 that are backed by buffer objects. In order to do that you change to a different type of EXA for which the current hack solution 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:

read -> hey I'm not tiled -> go linear access

This 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.

As usual, our short news:

- Libdrm (Upstream) got all of our fixes and patches needed for Nouveau.
- Our EXA implementation got a bunch of fixes allowing for much fewer software fallbacks (meaning more accelerated functions).
- Darktama has KMS for NV5x+ somewhat working which is based on efforts from stillunknown. Stillunknown in turn is putting his work on Nouveau KMS on hold until the memory managing code gets really useful (see here and here).