Where Things Fall Short: Eight Shortcomings Of Mesa 8.0

Written by Michael Larabel in Mesa on 11 January 2012 at 11:51 AM EST. 32 Comments
While Mesa 8.0 has a lot to like about it from advertised OpenGL 3.0 support to performance improvements and new Gallium3D features, there are also several shortcomings of this major Mesa release for open-source graphics drivers.

This article isn't meant to discount the work done by these open-source developers, since after all there's nearly 200,000 lines of new code since mesa-7.11 was tagged just a half year ago (albeit over 450,000 lines of code deleted), but just to show some of the shortcomings should you be interested in contributing to the Mesa project or wondering why the Unigine Engine isn't magically running well on Mesa, etc.

Incomplete OpenGL 3.0: While OpenGL 3.0 / GLSL 1.30 can be handled by core Mesa, GL3 support isn't in place for all of the hardware drivers. As said now in multiple Phoronix articles, the best OpenGL compliance in Mesa 8.0 will be found with Intel Sandy Bridge and Ivy Bridge hardware. There should also be "good" OpenGL 3.0 support within the Gallium3D Softpipe driver for slowly running GL off of your CPU. The ATI/AMD Radeon and NVIDIA (Nouveau) drivers are moving closer to full OpenGL 3.0 compliance, but they're not there yet for this Mesa release coming in February. Mesa 8.0 is to be branched today and after that only stable bug-fixes will be permitted into the 8.0 series code-base. By the time the Radeon and Nouveau drivers are caught-up, the OpenGL 3.0 specification from the Khronos Group will have been around for about four years. The LLVMpipe driver also doesn't have as full OpenGL 3.0 support as Softpipe within Mesa 8.0, since it's more difficult adding some features due to needing to deal with LLVM.

Other Missing OpenGL Functionality: Beyond the OpenGL 3.0 support coming about four years late, Mesa still has to catch-up on several newer versions of OpenGL: 3.1, 3.2, 3.3, 4.0, 4.1, and 4.2. A good chunk of work has been completed for OpenGL 3.1/3.2 compliance in Mesa, but there's still a lot to do in the GL Shading Language (GLSL) land and a whole lot more when it comes to OpenGL 4.x. It will likely be several releases of Mesa before seeing OpenGL 4.0 compliance met, by then there will probably be OpenGL 5.0.

OpenCL: The "Clover" branch of Mesa has yet to be merged to master, so there is still no Open Computing Language (OpenCL) support for Gallium3D. Hopefully this will come for the next cycle with the pieces of OpenCL support in the open-source GPU drivers finally coming together, but alas we're still playing catch-up to the latest industry standards and what is supported by the closed-source cross-platform graphics drivers. OpenCL 1.0 came in 2009 and since then there's already been the OpenCL 1.1 and 1.2 updates. (Granted, not all of the OpenCL lagging falls on Mesa but some kernel DRM work is also needed too by the drivers.) Right now there is work going on for OpenCL Gallium3D via an X.Org EVoC project after a fair amount of work was accomplished this summer via Google Summer of Code.

Slow Performance: While Mesa may be bettering its OpenGL compliance, it still doesn't mean you can play all the same games you do with the same hardware using the closed-source/proprietary drivers. The Radeon and Nouveau drivers are still generally much slower than the closed-source AMD and NVIDIA Linux graphics drivers. For some older hardware on R300g and certain Nouveau cards the performance is reaching a comparable point in select older OpenGL games/benchmarks, but as a whole the performance is still a ways off from the proprietary drivers. At least Intel's DRI driver in supporting Sandy Bridge is nearly comparable under Linux to the Windows driver. New Mesa 8.0 benchmarks doing such comparisons will be completed soon, but for now read The Most Comprehensive AMD Radeon Linux Graphics Comparison and A 14-Way Comparison Of NVIDIA vs. Nouveau Drivers.

S3 Texture Compression (S3TC): Also inhibiting Linux desktop users with the Mesa drivers is the lack of S3 Texture Compression support. S3TC is used widely by commercial games for texture compression, but it's not implemented in the moment in mainline Mesa and thus not supported. This has been a troubling spot for a number of years. In recent months it looked like S3TC may go into Mesa, after it looked like the S3TC patent by S3 Graphics might be invalid and HTC joining the Open Invention Network (HTC now owns S3 Graphics), but Mesa 8.0 is branched and there is still no S3TC support enabled. I've reached out to Ian Romanick at Intel about the S3TC state (he was the one that I previously talked with about the patent validity), but have yet to hear back.

At least for S3TC though there is support available if building the out-of-tree libtxc_dxtn library (see the FreeDesktop.org S3TC page). No major Linux distribution is shipping with this library by default, leaving most open-source graphics users without S3TC support unless they build this library -- assuming they even know about its existence.

Other Patent / Legal Issues: S3 Texture Compression is most often talked about when it comes to patents and legal issues inhibiting Mesa, but with more recent versions of OpenGL there are also other legal issues. For example, floating point textures is currently in Mesa but disabled by default. Floating-point textures is an OpenGL 3.0 feature, but covered by patent (this time by Silicon Graphics). Enabling the floating-point texture support in Mesa drivers requires re-building Mesa with a non-default build switch. Unlike the S3TC support, floating-point textures can't be easily provided by an external library. Floating-point depth buffers are also tied up with these legal issues. Arch Linux does enable the floating-point support as part of its configuration, but aside from this rolling-release distribution there aren't any other major vendors daring to enable the code.

Missing Hardware Support: Intel provides pre-launch support for new hardware (with Mesa 8.0, Ivy Bridge is ready months ahead of the product debut), but not to be found in this Mesa release is support for the Radeon HD 7000 "Southern Islands" series as introduced in December. This support is requiring a new Gallium3D driver to be created (albeit its derived from R600g) and there's also no DRM/KMS driver yet. Likewise, there's no early support for the GeForce 600 "Kepler" series, but that's no surprise at all considering NVIDIA's lack of open-source support and leaving it to the community to reverse-engineer after the fact. In terms of already existing hardware, there is no Mesa driver for Intel Poulsbo (PowerVR) hardware nor is there any Gallium3D driver yet that's in the tree for VIA graphics hardware. The same can also be said for missing 3D user-space support for the Samsung Exynos, Texas Instruments OMAP, and other embedded ARM graphics platforms.

???: Within the forums you can name what you think the eighth shortcoming of Mesa 8.0 is or what issue(s) you currently have with this open-source graphics library. Better operating system support? Better video acceleration? More work on the Direct3D state tracker? The removal of the DRI1-only drivers? Intel still not jumping on Gallium3D?
Related News
About The Author
Michael Larabel

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 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 OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via MichaelLarabel.com.

Popular News This Week