LLVMpipe May Be A Bit Closer To Running GNOME Shell

Last month we looked at the performance of the Gallium3D LLVMpipe driver that can provide software acceleration for the OpenGL-Mesa state tracker (among other state trackers via this driver architecture) on any modern CPU via LLVM (the Low-Level Virtual Machine) to optimize and handle these operations much more efficiently than the traditional Mesa software rasterizer.

The performance of LLVMpipe obviously was nowhere near the speed of using a proper GPU hardware driver with Gallium3D, but it was definitely a step-up from Mesa's software rasterizer that is simply unusable crap. Some games were close to being playable using LLVMpipe atop a very fast, multi-core CPU thanks to the geometry pipeline and other additions to this software driver.

While LLVMpipe is able to run OpenGL games, we then tested to see if LLVMpipe could run the GNOME Shell or Compiz, which need OpenGL but are not nearly as taxing on the graphics as a normal game. If LLVMpipe could efficiently handle running GNOME Shell it would mean a lot for providing a better "out of the box" experience for systems where there is no open-source 3D driver available by default with the GNOME 3.0 desktop. However, Compiz nor the GNOME Shell had worked with LLVMpipe at that time.

The problem was largely attributed to the software rasterizer / LLVMpipe lacking support for the GLX_EXT_texture_from_pixmap extension. This was the extension that was needed with the original Compiz upbringing and it took a while for ATI to drive that support in their Catalyst / fglrx Linux driver but now that texture from pixmap extension can be found in pretty much every open- and closed-source Linux graphics driver.

Fortunately, Red Hat's David Airlie has now created a patch that adds the texture from pixmap (TFP) support to Mesa's software rasterizer (the "swrast" driver). The patch was published this morning on the mesa-dev mailing list. David mentions with this patch he can "run gnome-shell inside Xephyr slowly. I've no idea why I did it, and g-s has other rendering issues under swrast, but it might be useful to hook up llvmpipe later. I've no idea if I even want to commit it at this point."

This patch is just a couple dozen lines of code and obviously isn't really beneficial quite yet but will hopefully be once hooked into LLVMpipe and the other GNOME Shell issues are addressed.