With Unity 2D being abandoned
and only providing Unity + Compiz in Ubuntu 12.10
as the default desktop, the out-of-the-box experience for low-powered ARM hardware on the stock Ubuntu desktop is a mess.
Last month the decision was made by Canonical to do away with Unity 2D now that LLVMpipe
is coming into shape as a decent Gallium3D software rasterizer inside Mesa. LLVMpipe has been talked about since its very early days on Phoronix for running OpenGL on the CPU
. With this being the default software fallback now in order to support Compiz, rather than going with the Qt-based Unity 2D, it's okay for x86 users.
In the x86 world most hardware has open-source 3D drivers that ship "out of the box" in Ubuntu so you always have 3D hardware acceleration and never have to worry about this Compiz/Unity-over-LLVMpipe. If you don't have a hardware driver or have to deal with this software fallback for a few minutes until getting around to installing the proprietary graphics driver, LLVMpipe is okay. LLVMpipe is powerful enough on a modern multi-core x86 CPU to handle the compositing window manager, especially if you're running 64-bit software and your CPU supports modern features like SSE4 and emerging AVX support
In the ARM world, it isn't quite as smooth. While there's projects materializing like Lima
for ARM Mali graphics, Freedreno
for Qualcomm hardware, and other emerging open-source reverse-engineering graphics on ARM SoCs, none of the 3D support is yet at a proper stage for end-users. As such, these open-source ARM 3D drivers aren't shipping in Ubuntu so basically there is no out of the box 3D support for Ubuntu on the ARM desktop.
Ubuntu does package like the official OMAP binary blob for 3D support, but it's not enabled by default, just the open-source kernel mode-setting drivers like OMAPDRM and the Samsung Exynos DRM. Therefore if you happen to be manually installing Ubuntu ARM's desktop image with 12.10 Quantal, you will always be hitting this LLVMpipe desktop fallback, at least initially until installing the binary graphics drivers.
Many Phoronix readers have been wondering what the current Unity experience is now like having this Unity 2D support removed, so here's some pictures from running the PandaBoard ES with the official OMAP4 Ubuntu 12.10 Beta
desktop image... It's just outright broken for now:
The PandaBoard ES OMAP4460 boots up, Plymouth appears with the OMAPDRM driver being loaded, and when it comes to loading the Unity desktop, the above pictures show what happens. That's the end of the story for where it's at now.
Gallium3D's LLVMpipe driver on ARM can work: with Fedora 17 on the PandaBoard ES the GNOME Shell with Mutter does work, albeit it's not the fastest desktop when using this software graphics acceleration. LLVMpipe implements OpenGL 2.1 with support for some newer GL3 extensions, although these problems experience here might be related to some fallout from the recent OpenGL changes in Compiz
. Regardless, be forewarned that if you're using ARM development boards like the PandaBoard and hoping to try out these Ubuntu 12.10 snapshots, it might not be a pleasant "out of the box" experience.
Hopefully this situation will be resolved by Ubuntu 12.10 final in October, but even still the default LLVMpipe experience on ARM will likely be sluggish due to lack of ARM-specific optimizations as well as the current-generation ARMv7 hardware not being too fast for handling this software rasterizer.
My suggestion for those manually playing with the Ubuntu ARM images that care about a desktop would be to use the Ubuntu ARM server pre-installed image. From there you can boot directly to a console, which is nice thanks to the KMS support from OMAPDRM. After that you can install Xfce or LXDE and have a much more pleasant experience rather than dealing with the Unity situation. If you just care about Ubuntu ARM on the server, you have nothing to worry about.
While out of the scope of Ubuntu 12.10, longer-term I hope Ubuntu, Linaro, and/or other developers will tackle ARM optimizations within Gallium3D/LLVMpipe. ARM NEON support within LLVMpipe is a potential area for some speed-ups along with other general optimizations, which are common for this LLVM-based software driver in x86 but there hasn't been much ARM work by Mesa developers.
In talking with some of the Linaro developers recently, it may be tough to sell the idea to Linaro for working on Mesa/Gallium3D improvements since the ARM vendors backing Linaro and deciding where resources are to be allocated are more geared towards Android's advancement. Mesa does work on Android
, but it's not in any real use in the Android ARM world at this point, so the investment may be hard to justify for the SoC vendors. Though when the LLVMpipe driver is able to handle things like the Clover state tracker
for OpenCL on the processor or other interesting use-cases, besides OpenGL with the Mesa state tracker, new doors might be opened...
It's a pity though there's now these Ubuntu ARM desktop troubles for 12.10 since overall the ARM support is in great shape: Ubuntu 12.10 Sets To Make ARM Even Stronger
, Ubuntu 12.10 Prepares To Improve Linux Performance
, and Ubuntu 12.10 Continues Strong On The PandaBoard ES
, among other Ubuntu 12.10 articles