LLVMpipe Doesn't Yet Like The GNOME Shell

Written by Michael Larabel in Mesa on 5 May 2010 at 11:00 AM EDT. 16 Comments
MESA
Last week we published our first benchmarks of LLVMpipe, which is a new driver for Gallium3D that's to serve as a software rasterizer on the CPU. LLVMpipe is ideal for cases where a GPU is not available or supported and it leverages LLVM (the Low-Level Virtual Machine) for optimization and providing much better software acceleration than Mesa's traditional software rasterizer or Gallium3D's previous Softpipe driver. LLVMpipe really likes modern, fast processors with SSE3/SSE4 support especially for best performance, but will work with nearly any 64-bit Intel/AMD processor. Unfortunately, LLVMpipe doesn't yet play well with GNOME Shell.

In those benchmarks last week where we used the Mesa state tracker from Gallium3D with the LLVMpipe driver to accelerate the operations on the Intel Core i7 processor, the OpenArena game was basically playable in this configuration at low resolutions but much slower than the classic Mesa or Gallium3D drivers for an ATI Radeon R500 series graphics card. While OpenArena ran fine on LLVMpipe, the GNOME Shell isn't yet working well when being accelerated by this software stack.

One of the major features being worked on for GNOME 3.0 is the GNOME Shell, which provides a new way to manage the GNOME desktop and it's integrated with the Mutter compositing window manager for a pleasing experience -- assuming you have hardware acceleration. The Clutter tool-kit depends upon OpenGL / OpenGL ES for drawing and thus needs 3D acceleration like from the Intel/ATI/NVIDIA-Nouveau Mesa or Gallium3D drivers or using the NVIDIA/ATI proprietary graphics drivers. To no surprise, Mesa's software rasterizer is not fast enough to handle the Mutter/Clutter operations with its software paths and doesn't even render the screen correctly.

We were interested to see whether LLVMpipe would work with the GNOME Shell/Mutter efficiently, so we tried it out on Ubuntu 10.04 LTS with LLVM 2.7 and a Mesa stack that was checked out from Git on 2010-05-05 (up through this commit). This was from a Mac Mini setup with an Intel Core 2 Duo processor, but unfortunately, LLVMpipe and the Mesa state tracker do not yet play well with GNOME Shell and its underlying Clutter pinnings.


When starting the GNOME Shell with LLVMpipe on Gallium 0.4 via this latest Mesa code, the screen turned out like what is shown in the above screenshot. The screen was mostly black except for a few icons coming through. This is similar to how the classic Mesa software rasterizer attempts to handle running GNOME Shell, but with LLVMpipe it ended up exiting out of the GNOME Shell a few seconds later with a signal status of 11 or signal 5 when LLVMpipe was built with the debug options. For reference, when attempting to launch Compiz with LLVMpipe and the Mesa state tracker it currently results in a white screen.

It's a pity that LLVMpipe isn't yet playing well with the GNOME Shell and Mutter/Clutter, but hopefully by the time that the GNOME 3.0 desktop is rolled out in September, this LLVM-assisted software driver will work well. This would allow those with a modest processor but no GPU hardware driver (such as those into open-source drivers but don't yet have a Mesa/Gallium3D driver, like those waiting on the ATI Radeon HD 5000 series 3D support) or in potentially a virtualized environment without guest 3D support to be able to use GNOME's new compositing manager and shell.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via MichaelLarabel.com.

Popular News This Week