1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Reasons Mesa 9.1 Is Still Disappointing For End-Users

Mesa

Published on 14 February 2013 08:24 PM EST
Written by Michael Larabel in Mesa
37 Comments

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.

Latest Linux Hardware Reviews
  1. Mini-Box M350: A Simple, Affordable Mini-ITX Case
  2. Overclocking The AMD AM1 Athlon & Sempron APUs
  3. AMD Athlon 5350 / 5150 & Sempron 3850 / 2650
  4. Upgraded Kernel & Mesa Yield A Big Boost For Athlon R3 Graphics
Latest Linux Articles
  1. A Quick Look At GCC 4.9 vs. LLVM Clang 3.5
  2. Are AMD Athlon/Sempron APUs Fast Enough For Steam On Linux?
  3. AMD Athlon's R3 Graphics: RadeonSI Gallium3D vs. Catalyst
  4. GCC 4.9 Compiler Optimization Benchmarks For Faster Binaries
Latest Linux News
  1. Fedora 21 Gets GNOME 3.12, PHP 5.6, Mono 3.4
  2. Fedora Workstation Is Making Me Quite Excited
  3. Maynard: A Lightweight Wayland Desktop
  4. Chromium Browser Going Through Growing Pains In Ubuntu 14.04
  5. KDE 4.13 Is Being Released Today With New Features
  6. Trying Out Radeon R9 290 Graphics On Open-Source
  7. Intel Broadwell GT3 Graphics Have Dual BSD Rings
  8. Early Linux 3.15 Benchmarks Of Intel Core i7 + Radeon
  9. Red Hat Releases Its RHEL 7 Release Candidate
  10. New Features Coming To Xubuntu 14.04 LTS
  11. NVIDIA Officially Releases CUDA 6
  12. Google Releases An AutoFDO Converter For Perf In LLVM
Latest Forum Discussions
  1. The GNOME Foundation Is Running Short On Money
  2. Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
  3. Change installation destination from home directory
  4. After Jack Keane, RuseSoft will briing Ankh 3 to Linux through Desura
  5. Bye bye BSD, Hello Linux: A Sys Admin's Story
  6. New tool for undervolt/overclock AMD K8L and K10 processors
  7. How to enable opengl 3.3 on r9 270?
  8. R290x sound problems