[Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

[Jose Fonseca]

On 26/08/14 18:59, Matt Turner wrote:
> On Tue, Aug 26, 2014 at 9:00 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> If LLVM was a useless piece of junk, we wouldn't have any trouble adding it
>> as a dependency, as we would be the sole user.  But precisely because LLVM
>> is successful in so many use cases, hence several packages depend on it, we
>> shouldn't depend, so we can avoid the dealing with the oh-so-hard dependency
>> issue!?  I find it ridiculous: it's precisely because LLVM is potentially
>> that good that it makes sense for us/distros/everybody to put up with the
>> dependencies issues it may bring, and worth considering.
>
> It sounds like there are enough people in the Mesa community that are
> familiar with LLVM and interested in using it in the GLSL compiler
> that there would be someone willing to start working on it. Hopefully
> that's the case.
>
> I tried going through the LLVM language frontend tutorial on LLVM.org
> and only had to get to chapter 4 (the first two chapters don't use
> LLVM) before the code didn't compile (and I couldn't figure out why)
> with LLVM 3.4 on my system. I found this [1] tiny example (not updated
> for 2 years) using the C API and thought it'd probably not work
> either, but was happily surprised that it compiled and worked fine. I
> see that the C API is used in radeonsi and gallivm in Mesa.
>
> Here's what I think would be compelling: Using the stable C API,
> translate from GLSL IR into LLVM IR. Call LLVM's optimizations. Give
> backends the option to consume LLVM IR. From here we can evaluate just
> how significant the improvement from LLVM's optimizer is. At least two
> people have written GLSL IR -> LLVM translators in the past -- Luca
> Barbieri (what ever happened to him?!) and Vincent Lejeune (Cc'd).
> Their code is [2] and [3]. I think this plan would also fit nicely
> with existing LLVM backends, potentially avoiding a trip through TGSI.
>
> I think this is strictly superior to other ideas like throwing out the
> GLSL frontend and translating LLVM IR back "up" to the higher level
> GLSL IR.
>
> So, maybe some people experienced with LLVM from VMware and AMD are
> interested in taking the lead?
>
> [1] https://urldefense.proofpoint.com/v1/url?u=https://github.com/wickedchicken/llvm-c-example&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=elDze1klTx%2FGG4BGj4lLADbJiCzPhdZLgxbI5fFm2WE%3D%0A&s=7d02b29a8898b7187583d4d9587afd240f91a33f043aec747ec29d828c1a1e87
> [2] https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/~anholt/mesa/log/?h%3Dllvm-4&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=elDze1klTx%2FGG4BGj4lLADbJiCzPhdZLgxbI5fFm2WE%3D%0A&s=35a72642df7aa1782206c3ddb5c6a1094e74bb2cf6e9b0ca55656269231a9a87 (Eric's
> branch based on Luca's code)
> [3] https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/~vlj/mesa/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=elDze1klTx%2FGG4BGj4lLADbJiCzPhdZLgxbI5fFm2WE%3D%0A&s=a81938751d88ad6f85a3c99d9a5215a9968fcce083b147480bea00d41f3961d9 (one of the glsl-to-llvm* branches)
>


It happens that the optimization quality of the incoming GLSL code is 
for the most part irrelevant for VMware drivers (*).   So I'm afraid I 
don't see us at VMware staffing any sort of GLSL -> LLVM initiative in 
the near future.

So, even though it seems to me that Mesa will unavoidably eventually 
gravitate towards more wide-spread use of LLVM, I'm unable to help 
provide more critical mass myself.

Which is why I don't oppose NIR.  Even though it seems a less direct 
path than overcome the hurdles of using LLVM now, NIR's SSA-nature seems 
a step forward nevertheless.  And of course, who does the job gets to 
decide how it's done.



But in terms of taking a lead towards GLSL -> LLVM, LunarG seems to be 
quite ahead with their GlassyMesa/LunarGlass proof-of-concepts which is 
BSD-licensed:

  http://lunarg.com/glassymesa/
 
http://testing.lunarg.com/wp-content/uploads/2014/06/GlassyMesaSlides-08Jun2014.pdf
  http://lists.freedesktop.org/archives/mesa-dev/2014-June/061140.html

They use Glslang frontend instead of glsl2 frontend, but it's probably 
not hard to retrofit it into consuming glsl2 ir if that makes things 
easier.  So maybe somebody could look into leveraging some this work.

I believe that a key challenge with LLVM is in extending LLVM IR to 
represent graphics shaders effectively, but it looks like this has been 
explored quite deeply per http://www.lunarglass.org/documentation , in 
particular
http://www.lunarglass.org/documentation/LunarGLASSSpecification1.2.pdf


Jose


(*) Because on all the drivers we care for GLSL shaders end up being 
compiled and optimized after we are done with them:

- in the vmware svga driver the host graphics drivers will compile and 
optimize them.

- in llvmpipe we pass the shaders LLVM which will optimize them before 
it generates native machine code

That is, as long as GLSL doesn't obfuscate/pessimizes the shaders, and 
information is preserved relatively unmolested, we're good.

I think we'll care more about the IR if/when we tackle compute on the 
drivers mentioned above, as TGSI will probably be inadequate to 
represent the incoming compute kernels.  So I expect we'll want to 
consume LLVM IR directly, and I also suppose we'll eventually want to 
drop TGSI and consume LLVM alone.