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

Mesa Beginning To Need Application Workarounds

Mesa

Published on 26 January 2012 08:26 AM EST
Written by Michael Larabel in Mesa
19 Comments

Now that Mesa is beginning to catch-up with support for newer versions of OpenGL and the OpenGL performance is slowly improving, with more games and applications beginning to work on this open-source graphics driver stack as a result, the need for application workarounds is becoming more prevalent.

OpenGL game/application workarounds aren't new in the world of the binary GPU drivers, especially on Microsoft Windows. The Windows drivers from AMD and NVIDIA contain heavy application-specific optimizations and workarounds. These workarounds are in place to provide greater performance in some OpenGL workloads by automatically tweaking the driver settings while in other cases the application-specific workarounds are to workaround bugs within a given piece of software.

The bug workarounds tend to happen when the game or application isn't written strictly to comply with the OpenGL specification or the software itself was written intentionally to be non-compliant so that it could workaround a bug (or other shortcoming) in a given driver at the time of the software shipping. The Catalyst driver also uses a static application list for determining when multi-GPU CrossFire support should be enabled.

Within the Mesa stack, developers are finally reaching that point -- for better or worse -- of needing application workarounds. Eric Anholt of Intel has posted a patch to the Mesa-dev mailing list that begins handling workarounds.

The first application Intel is attempting to address with an application-specific workaround is the Unigine Sanctuary tech demo, which needs a small change to take care of a GLSL bug in this older Unigine Engine demo for the i965 Mesa DRI driver.

Still somewhat up in the air is how to handle these application workarounds. This initial patch from Eric Anholt is lodging the application workarounds within the drirc file, which is the file commonly holding various Mesa settings that can be tweaked by users such as for the S3TC options, anti-aliasing, etc. Placing application workarounds by default in this file though will result in more systems having a drirc, since right now it's not actually too common for users to tweak the file or to even know about its existence.

Having the file external from the Mesa build makes it easier to maintain and to adjust accordingly when the software in question is fixed or other changes made, without the user needing to rebuild Mesa. Alternatively, there could be a new XML file for housing application-specific workarounds, such as is done by the AMD Catalyst Linux driver. Also being questioned is whether the software binary name should be used as the basis for determining whether to apply one of these "hacks" or whether to look at what libraries are being loaded -- so that blanket changes could be made across all games using a particular engine (for instance, if checking for a loaded Unigine library).

The current discussion over per-application workarounds via drirc begin with this mailing list message.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  2. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  3. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
  4. AMD Radeon R9 285 Tonga Performance On Linux
Latest Linux Articles
  1. 6-Way Ubuntu 14.10 Linux Desktop Benchmarks
  2. Ubuntu 14.10 XMir System Compositor Benchmarks
  3. Btrfs RAID HDD Testing On Ubuntu Linux 14.10
  4. Ubuntu 14.10 Linux 32-bit vs. 64-bit Performance
Latest Linux News
  1. Mono Brings C# To The Unreal Engine 4
  2. Coreboot Now Has Support For Intel Broadwell Hardware
  3. Enlightenment's EFL 1.12 Alpha Has Evas GL-DRM Engine, OpenGL ES 1.1 Support
  4. GTK+ Lands Experimental Backend For Mir Display Server
  5. Ubuntu 14.10 Officially Released
  6. Mesa 10.4 Might Re-Enable HyperZ For R600g/RadeonSI
  7. Intel GVT-g GPU Virtualization Moves Closer
  8. GTK+ 3.16 To Bring Several New Features
  9. Debian 8.0 Jessie Has Many Multimedia Improvements
  10. What Linux Benchmarks Would You Like To See Next?
Latest Forum Discussions
  1. HOPE: The Ease Of Python With The Speed Of C++
  2. Linux hacker compares Solaris kernel code:
  3. Advertisements On Phoronix
  4. Updated and Optimized Ubuntu Free Graphics Drivers
  5. Users/Developers Threatening Fork Of Debian GNU/Linux
  6. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. Proof that strlcpy is un-needed