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.
- 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.
- 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.
- 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.
- 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