The perils of the bleeding edge

After my fun playing with the 3D desktop bling on my Netbook I finally took the plunge on my main desktop machine. This was after all the reason I had specced it with hardware capable of doing 3D with open drivers. In the beginning it worked well enough but it had a small fly in the ointment that video playback was jerky.

Video generates all sorts of interesting problems for graphics, especially when dealing with 3D. The central point about a 3D desktop is every 2D window renders onto it's own little bit of memory which is then used as a texture for 3D objects when the screen is rendered. This works fine for windows that only update every few seconds but it puts a strain on the video bus for 25fps of Hi-Def video data.

Fortunately X hackers have come up with solutions to this. The main one being off-loading some of the video decoding into the video chip using an extension called XvMC (and an earlier extension called Xv). Unfortunately these features where not supported in the "stable" version of the graphics drivers for X. This started a round of upgrading X which coincided with moving up kernel versions and a drastic drop in performance. The recent introduction of the GEM graphics memory manager has regressed my particular chipset (bug 1 and bug 2). I'm presented with the choice of waiting nicely for the fix to percolate into an official release or manning up and getting my compiling shoes on.

One aspect of Xorg compilation that usually gives people the willies is the fact it's rather complex. The system has kernel components, 2D drivers and 3D drivers as well as the host of X libraries. The only real sane way of dealing with it without bringing your workstation down around your ears is to build a parallel X install. Luckily it seems a simpler process than when I last looked into it. However it is a long one so it will take a while before I'm in a position to try it out.