We Rely On Your Support: This site is primarily supported by advertisements. Ads are what have allowed this site to be maintained for the past 12 years. We do our best to ensure only clean, relevant ads are shown, when any nasty ads are detected, we work to remove them ASAP. If you would like to view the site without ads while still supporting our work, please consider our ad-free Phoronix Premium. You can also consider a tip via PayPal.

While Mesa 9.1 represents a number of improvements to this open-source graphics stack that were made over the past six months, as far as end-users are concerned, there's still a number of shortcomings.

Shared earlier today were Nine Exciting Features Coming To Mesa 9.1. There's truly some great new features and work found in Mesa 9.1 made by both paid and volunteer developers. However, for end-users of the Linux desktop simply wanting their graphics drivers to "just work" and be on par with the proprietary graphics drivers, there's still a ways to go.

OpenGL 4.3 - The latest upstream OpenGL specification from the Khronos Group is OpenGL 4.3. Meanwhile, Mesa 9.1 is only in official compliance with OpenGL 3.1. Mesa is still years behind on desktop OpenGL support. For the next Mesa release in six months time we'll likely be at OpenGL 3.3 compliance, but OpenGL 4.0 is unlikely to be seen before 2014. Before OpenGL 4.0 support arrives to the open-source Mesa, it won't be surprising if Khronos has OpenGL 5.0. Unless there's some fundamental change to how Mesa is developed or the rate at which new OpenGL specifications are ratified, it will be quite a while before Mesa is caught up with the proprietary drivers that are already doing OpenGL 4.x. Even the Intel Windows driver is ahead in this area.

OpenCL - This also concerns the kernel DRM and other areas, but there is still no viable open-source OpenCL support on the Linux desktop. There's been mild progress lately, particularly by Tom Stellard at AMD on improving the R600 LLVM GPU back-end, but the OpenCL support still leaves a lot to be desired. With Nouveau and Radeon Gallium3D, some basic OpenCL tests should be able to execute on the GPU, but this support isn't found in any "out of the box" way with Linux distributions and more real-world OpenCL tasks aren't yet readied on this stack.

S3TC / Floating-Point Textures / Patents - Intel made progress on the patent/legal situation in that Mesa 9.1 they are now unconditionally enabling the OpenGL floating-point textures support for their Mesa DRI driver. However, the compile-time switch is still required for the Radeon and Nouveau drivers. Additionally, there still isn't any official S3TC texture compression support due to patents.

No More VA-API - The Gallium3D VA-API state tracker was removed from Mesa. At least there is the VDPAU state tracker that is more developed within Gallium3D and is in a working state. However, this video acceleration is still done using GPU shaders rather than say the AMD UVD video engine.

Anti-Aliasing - While multi-sample anti-aliasing has seen improvements in the Mesa 9.1 cycle where it is now available by default for the old Radeon X1000 series GPUs with R300g, it's still not available to all hardware generations supported by Mesa, it's basically only 2/4/8x MSAA, and the more advanced anti-aliasing modes are still not supported. Multi-sample anti-aliasing support has been common to Windows users for years and the proprietary drivers support more anti-aliasing modes not yet supported by Mesa/Gallium3D for enhanced image quality.

Performance Parity - There's been some performance improvements made to the hardware drivers found in Mesa 9.1, but as a whole, the open-source graphics drivers are still slower than the proprietary graphics drivers from the different vendors as many Phoronix tests have illustrated.

Gallium3D LLVMpipe - The LLVMpipe Gallium3D driver, which is commonly being used now as the default software fallback by Linux distributions -- including to run composited desktops like Ubuntu Unity and GNOME Shell -- still comes up short. LLVMpipe still doesn't have full GL3 support even though it's a software-based driver. LLVMpipe officially advertises OpenGL 2.1 compliance right now while the hardware drivers move ahead in the GL3 era. LLVMpipe also is still rather slow and mostly unusuable for ARM, even as the number of Linux ARM devices is on the rise. For more reasons why LLVMpipe still leaves a lot to be desired, read Not All Linux Users Want To Toke On LLVMpipe.

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 10,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 or contacted via MichaelLarabel.com.

The mission at Phoronix since 2004 has centered around enriching the Linux hardware experience. In addition to supporting our site through advertisements, you can help by subscribing to Phoronix Premium. You can also use our Amazon.com or NewEgg.com shopping links when making online purchases or contribute to Phoronix through a PayPal tip.