While LLVM 2.8 was just released, we have been curious to see how the latest Low-Level Virtual Machine compiler code affects the performance of the LLVMpipe driver. This is the Gallium3D graphics driver that lives in Mesa and leverages the unique modular LLVM compiler to efficiently handle processing the graphics rendering workload on a modern CPU as a much faster alternative to that of their legacy software rasterizer. To see how much of a performance impact - for better or worse - that LLVM 2.8 has on this open-source software driver we tested it when being built with LLVM 2.6, 2.7, and the 2.8 SVN code.
Is it only me or lately llvmpipe has been disabled in xorg-edgers? Since about a week, running LIBGL_DRIVERS_PATH="/usr/lib/dri/gallium" glxinfo|grep renderer outputs OpenGL renderer string: Gallium 0.4 on softpipe
DRI experimental and Llvm are installed, of course.
Every sane GL library needs a software fallback for the case that the driver does not implement hardware acceleration for particular functionality. In that case, the CPU is used to perform such operations. It will be considerably slower, but at least it will render correctly, which is what the library is supposed to do.
Mesa implements all of OpenGL in software, for such a case. The individual hardware drivers in Mesa then accelerate most of the things so you never need to run the software (CPU-based) path.
Gallium3d has the same thing, and it's called softpipe. You can run OpenGL programs on that, but it's very slow.
llvmpipe uses llvm (http://en.wikipedia.org/wiki/Llvm) and serves as a replacement for softpipe. Although everything is run on the CPU, it is much faster than softpipe, and can even offer acceptable performance for some simpler tasks.