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's IR Might Get Changed Around Amid Discussions

Mesa

Published on 29 May 2014 11:19 AM EDT
Written by Michael Larabel in Mesa
5 Comments

In a new mailing list thread, Eric Anholt expresses regrets a few years ago when they began sending GLSL IR into their driver rather than using Mesa IR and improving that intermediate representation. Eric is now trying to get the Mesa IR support up to scratch so that it can be sent directly to classic Mesa drivers.

Eric Anholt of Intel's Open-Source Technology Center wrote:
Here's a series I started back in January as a little experiment. Basically, I feel guilty for pushing GLSL IR into the driver, and wish I'd just fixed up Mesa IR back in the day. But, given that we're still feeding Mesa IR into drivers as well (ARB programs and fixed function vertex programs), it made me think: What if I fixed it up now, and got Mesa IR to the point that we could just garbage collect the GLSL IR input paths to drivers?

Mesa IR has a bunch of weaknesses that need to get sorted out if it's going to be useful:

- It's a single giant array of instructions, making modifications of the instruction stream (instruction lowering, optimization, etc.) more expensive in code and CPU time than it should be.
- It doesn't have any variable declarations, so if you have dynamic array indexing, optimization just shuts down (plus, no annotation on the temps, so debugging is irritating).
- It doesn't have integer instructions or anything else post-GLSL-1.30.
- The optimization passes for it are totally ad-hoc and fairly weak.
- It's not SSA.

I'm interested in fixing all of these. How do people feel about this goal?

This series fixes the first bullet point above. Patch 15 is huge, but I didn't see a way to chop it up smaller without maintaining the list alongside the array for some intermediate patches. I'd be willing to do so if needed, though, to make review doable. You can also find the changes in the "mesa-ir" branch of my git tree.

In response fellow Intel OTC developer Ian Romanick expressed concerns that this change would regress other old Mesa drivers like ATI R200 and the i915 drivers where they seldom see new work, testing, etc. It's also a bit like reinventing TGSI, the intermediate representation used by Gallium3D drivers. "I'm not very excited about exposing i915, r200, and swrast to more potential breakage that nobody will notice until 5 minutes before a release... or 5 mintues after. Not wanting to touch prog_exec is one of the reasons we avoided making changes to Mesa IR in the first place. It also feels a bit like a re-invention of TGSI, and nobody seems particularly enamored with that IR either. That said, it may still be an interesting experiment."

Open-source contributor Connor Abbott also expressed some reservations about the proposed change and 16 initial patches. "I don't know much about Mesa IR, but this seems like a huge pile of work... is this any easier than just making GLSL IR flatter, like with my flatland idea that I posted a while ago? Also, iirc, there was an effort a while ago to make ARB programs go through GLSL IR but it was abandoned - why was it so difficult? I'm skeptical that basically bringing an older IR from 1999 to 2014 is going to be less effort than modifying a newer one that had some good ideas and some bad ones."

Intel OTC developer Kenneth Graunke also expressed concerns. "I'm still really skeptical of this goal. I don't think reusing the existing Mesa IR backend code will save you much effort...Our Mesa IR adapters are missing features and have bad assumptions. For example, the VP code doesn't do texturing at all. The FP code assumes texture units/sampler units work like ARB programs. Neither do control flow at all. Neither do integer types. They also generate terrible code with piles of temporaries. You could fix all of these things, but it would entail writing a lot of code. And when you're done, you still have to throw the 'big switch' where you decide to use the new path instead of the GLSL IR path."

The discussion is still ongoing via this mailing list thread for those interested in GPU driver IR and Mesa.

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. AMD R600g/RadeonSI Performance On Linux 3.16 With Mesa 10.3-devel
  2. Intel Pentium G3258 On Linux
  3. SilverStone Precision PS10
  4. ASRock Z97 Extreme6
Latest Linux Articles
  1. KVM Benchmarks On Ubuntu 14.10
  2. X.Org Server 1.16 Officially Released With Terrific Features
  3. Ubuntu With Linux 3.16 Smashes OS X 10.9.4 On The MacBook Air
  4. Preview: Benchmarking CentOS 7.0 & Scientific Linux 7.0
Latest Linux News
  1. Oracle Linux 7 Released Today As Its RHEL7 Clone
  2. Unigine Develops City Traffic System, A Driving Simulator
  3. Intel 3.0 X.Org Driver Still Baking, New Development Release
  4. Eric Anholt Makes Progress With Broadcom VC4 Graphics Driver
  5. Intel Is Getting Very Close To OpenGL 4.0/4.1/4.2 Mesa Support
  6. Valve Is Still Hiring For SteamOS, Linux Work
  7. Users Warned About Possible Regressions With DRI3
  8. GNOME Shell Gets Wayland HiDPI Fonts, Mutter Gets Touch Gestures
  9. BPTC Texture Compression Comes To Nouveau After Intel's Work
  10. Development Continues For Supporting EXT4 On NVDIMMs
Latest Forum Discussions
  1. Updated and Optimized Ubuntu Free Graphics Drivers
  2. Radeon related kernel bug??
  3. AMD Publishes Open-Source Linux HSA Kernel Driver
  4. Next-Gen OpenGL To Be Announced Next Month
  5. Open-Source Radeon Performance Boosted By Linux 3.16
  6. Remote gui not accessible in Phoronix Test Suite 5.2
  7. AMD "Hawaii" Open-Source GPU Acceleration Still Not Working Right
  8. In Road To Qt, Audacious Switches From GTK3 Back To GTK2