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 Benchmarking Platform
Phoromatic Test Orchestration

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 Articles & Reviews
  1. Sub-$20 802.11n USB WiFi Adapter That's Linux Friendly
  2. The Lenovo T450s Is Working Beautifully With Linux
  3. Linux 4.0 SSD EXT4 / Btrfs / XFS / F2FS Benchmarks
  4. Linux 4.0 Hard Drive Comparison With Six File-Systems
  5. Lenovo ThinkPad T450s Broadwell Preview
  6. How Open-Source Allowed Valve To Implement VULKAN Much Faster On The Source 2 Engine
Latest Linux News
  1. Daily Builds Of Wayland & Weston For Ubuntu Linux
  2. AMD Open-Sources "Addrlib" From Catalyst
  3. AMD Releases New "AMDGPU" Linux Kernel Driver & Mesa Support
  4. A Gigabyte Sandy/Ivy Bridge Motherboard Now Handled By Coreboot
  5. Linux 3.16 Through Linux 4.0 Performance Benchmarks
  6. Intel's Windows Driver Now Supports OpenGL 4.4, Linux Driver Still With OpenGL 3.3
  7. DRM Graphics Updates Sent In For The Linux 4.1 Kernel
  8. More eBPF Improvements Heading To Linux 4.1
  9. LLDB Is Getting Into Shape For Linux 64-bit Debugging
  10. Wine-Staging 1.7.41 Works On Improved Debugging Support
Most Viewed News This Week
  1. Nouveau: NVIDIA's New Hardware Is "VERY Open-Source Unfriendly"
  2. LibreOffice 4.5 Bumped To Become LibreOffice 5.0
  3. Linux Audio Is Being Further Modernized With The 4.1 Kernel
  4. KDBUS Is Taking A Lot Of Heat, Might Be Delayed From Mainline Linux Kernel
  5. VirtualBox 5.0 Beta 2 Released
  6. ZFS & Libdvdcss Should Soon Be In Debian
  7. Ubuntu 15.04 Now Under Final Freeze
  8. EXT4 In Linux 4.1 Adds File-System Level Encryption