Nine Reasons Mesa 9.0 Is Disappointing For End-Users

Written by Michael Larabel in Mesa on 9 October 2012 at 09:27 PM EDT. 37 Comments
While this morning I shared my views about nine good features of Mesa 9.0 for the major open-source OpenGL user-space update, there's also many disappointing items and shortcomings of this Mesa 9.0 release as it pertains to end-users running the open-source Linux graphics drivers.

The expressed issues aren't all necessary problems where the responsibility ends up in the hands of the Mesa developers, but general open-source graphics ecosystem problems as well.

OpenGL 3.1 vs. OpenGL 4.3: The big feature of Mesa 9.0 is that the Intel driver is now capable of OpenGL 3.1 compliance. While that's nice, the OpenGL 3.1 specification has been around since March of 2009 and that it's taken nearly four years for Mesa to support this version. The other open-source drivers like Radeon, Nouveau, and LLVMpipe are still at sub-GL3.1 levels.

Already having succeeded OpenGL 3.1 is OpenGL 3.2 from August of 2009, OpenGL 3.3 in March of 2010, OpenGL 4.0 in March of 2010, OpenGL 4.1 in July of 2010, OpenGL 4.2 in August of 2011, and OpenGL 4.3 in August of 2012. By the time that Mesa has caught up with the latest Khronos specification, there will surely be OpenGL 4.4 if not OpenGL 5.0. By the next Mesa release in six months I'm hopeful that OpenGL 3.3 support will be there for at least Intel and ideally the Radeon/Nouveau drivers, but we're probably at least one year out from seeing OpenGL 4.0+ on the open-source drivers.

Mesa has traditionally lagged a long time behind the Khronos OpenGL specifications. The proprietary AMD and NVIDIA drivers -- along with the Intel Windows driver -- has been quick to support new versions of the specification.

The OpenGL ES 3.0 specification has also been out since August but there's only OpenGL ES 1.1/2.0 in mainline Mesa. At least for GLES 3.0, Intel plans to get it working for the next Mesa release.

OpenCL Is Still Behind: Similar to the lagging OpenGL support, the OpenCL support for GPGPU computing is still a big action item. Mesa 9.0 saw the merging of the Clover state tracker plus basic Radeon and Nouveau work for this GPGPU compute specification, but it's still far from being usable for everyday Linux desktop users on the open-source drivers. The Intel Mesa driver also has no form of GPGPU/OpenCL support even though their latest hardware is capable.

Patent Mess: Due to patents and legal fears. there still is no mainline Mesa support for S3TC (S3 Texture Compression) as is commonly used still by many games and OpenGL applications. Users need to manually install a third-party library from source for having S3TC support on the open-source drivers. Floating-point textures / depth-buffers are also not enabled by default (Mesa needs to be built with --enable-textue-float) for having this critical part of OpenGL 3.0 enabled in the drivers.

Incomplete Hardware Support: While there's now the RadeonSI Gallium3D driver for providing Radeon HD 7000 series support (and eventually, Radeon HD 8000 series too), it isn't exactly usable to end-users. Alex Deucher describes the state of RadeonSI as "It currently runs lots of 3D demos and basic games, including piglit. I think the biggest thing left is shaking out the remaining bugs in the flow control code in the shader compiler. Once that's working properly we can enable more glamor features and more advanced games should start working." With the Radeon HD 7000 series they're also piping 2D over 3D/OpenGL via the GLAMOR library, so 2D is also a wreck until the 3D support is all fixed up. Hopefully most of the RadeonSI work will be back-ported to the Mesa 9.0 branch otherwise AMD customers are forced to wait more than one year after the hardware launched for there to be proper open-source driver support. (The HD 7000 series were introduced around the start of this year while the Mesa 9.1/10.0 release won't happen until Q1'2013.)

The early Nouveau support for the NVIDIA GeForce 600 "Kepler" series can at least handle games without major problems, but there the early hardware support is crippled by the kernel DRM driver not yet supporting re-clocking and other features for the new NVIDIA GPUs.

Slow Performance: The open-source Radeon and Nouveau drivers still aren't at the same level of OpenGL performance as the proprietary NVIDIA and AMD Catalyst drivers for Linux. As well, the open-source Intel Linux driver is slower than Intel's Windows driver. Though this isn't exclusively a Mesa problem as part of the equation comes down to the kernel DRM driver components too.

Upgrading Fears: While this comes down somewhat to a distribution vendor problem too, but upgrading a major Mesa release isn't as easy as it is installing a Windows GPU driver or the proprietary Linux graphics drivers, due to dependencies on the libdrm version and other requirements. Aside from the rolling-release distributions, most of the tier-one Linux desktop distributions don't risk shipping new major versions of Mesa as updates to existing Linux distribution releases. With the ~six month release cycle for Mesa, many end-users end up waiting a while before getting their hands on the improved Mesa code. At least though for Ubuntu and some other distributions there are third-party repositories available for those interested.

Non-Linux Support: While Mesa has traditionally been supported on the *BSD and Solaris operating systems, among other obscure operating systems, these days the Mesa development focus is almost exclusively around Linux. Most of the modern Mesa drivers won't work outside of Linux due to other kernels not supporting the memory management / DRM requirements and other needed functionality.

Video Acceleration: With Mesa 9.0, the VDPAU video state tracker for Gallium3D is marked as being effectively complete. Unfortunately, this is only accelerating MPEG1 and MPEG2 video formats, which aren't too incredibly useful for most of today's purposes. This video acceleration is also being done using GPU shaders as opposed to tapping into the dedicated video decoding engines found on modern graphics processors, e.g. NVIDIA PureVideo and AMD UVD.

Other Features: There's various other features still missing from the open-source graphics drivers like the more advanced anti-aliasing modes, CrossFire / SLI multi-GPU rendering, a useful graphics control utility (driconf is only minimally useful and doesn't compare to the utilities found within proprietary drivers), and other random features.

What other problems do you have with Mesa or the open-source graphics drivers in general? Share your list in the forums.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of 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 automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via

Popular News This Week