Reaching this milestone can be attributed to Red Hat, Google's Chrome/Chromium OS developers, and others working on the Mesa / Gallium3D software stack. Just recently LLVMpipe gained support for GLX_EXT_texture_from_pixmap, the GLX extension that's required by many Linux compositing window managers. These improvements allow the desktop effects to all be done on the CPU without any dependence on any GPU hardware driver. GNOME Shell on the VESA driver or within a KVM/QEMU guest is fair game.
Having returned from the Ubuntu 12.04 developer summit this weekend, I pulled the latest Fedora Rawhide packages on Sunday morning. These packages will ultimately be part of Fedora 17 (a.k.a. the Beefy Miracle, and not to be confused with the release of Fedora 16 this coming week).
When running Fedora 16 or other current Linux releases using the GNOME Shell in an environment without GPU driver support, the gnome-panel fall-back is used. Some actually prefer the GNOME3 fall-back to the GNOME Shell since it's more like the GNOME2 experience.
When using the Fedora Rawhide packages from this weekend, sure enough, the GNOME Shell now works in software without tapping the GPU! For those not familiar with the open-source LLVMpipe driver to begin with, read my original article on LLVMpipe from last year. Its performance has improved in the two or so years I have been closely monitoring this unique driver and fairs better with newer CPUs. Beginning with Fedora 15, LLVMpipe became the default software rasterizer (rather than the classic Mesa "swrast" that's nearly useless for end-users), but up until now hasn't been useful for the latest Linux desktops.
This testing was being done with the un-accelerated Cirrus X.Org driver (xf86-video-cirrus) in the KVM/QEMU guest from an Ubuntu 11.10 host. When allowing the Fedora Rawhide guest to only access one CPU core and 1GB of system memory, the performance of GNOME Shell over LLVMpipe was choppy and not as fluid as the GNOME3 panel fall-back or obviously when taking advantage of GPU hardware acceleration on bare metal. When allowing the virtual machine to take advantage of two CPU cores, the experience was much better, with still only 1GB of RAM. Red Hat has reported that using SPICE also improves the experience for GNOME Shell on this Gallium3D-based software driver.
LLLVMpipe is able to handle the GNOME Shell experience relatively well since it takes advantage of LLVM and is able to optimize for x86_64, multiple threads, and SSE instruction sets. As mentioned in Thursday's news posting, Red Hat will be working on other improvements to speed-up LLVMpipe during the Fedora 17 cycle (see the F17 feature specification). OpenGL gaming on LLVMpipe is slow and really won't be competitive, but will hopefully end up being a fairly pleasant experience for most hardware in handling compositing window managers with desktop effects. Optimization work for LLVMpipe on ARM and other architectures also needs to be completed.
Killing The GNOME3 Fall-Back?
As has been discussed in the past few days since the announcement of the milestone, once the latest Gallium3D LLVMpipe support is widespread and delivering decent performance, this may limit the life of GNOME developers maintaining the GNOME3 fall-back.
As said by Red Hat's Adam Williamson on the Fedora mailing list, "That's really a policy decision for the GNOME / Fedora desktop teams, not for ajax. But based on what they've said in the past, I expect that once most hardware that previously needed the fallback mode is covered, fallback mode will die. AIUI, fallback mode isn't meant to be a GNOME 2-by-stealth for Shell refuseniks, it's purely an attempt to accommodate hardware which doesn't support Shell."
Ubuntu Unity / Compiz On LLVMpipe
Now to see if the Unity desktop on Ubuntu with Compiz will work with the latest LLVMpipe advancements, rather than the Qt-based Unity 2D fall-back. Stay tuned to my Twitter for live updates.
(Speaking of GNOME, be sure to participate in the 2011 GNOME user survey. You can also see a stream of the comments and the largely angry feedback.)