[Mesa-dev] [PATCH 00/15] Compile GLSL to ir_builder

[Ian Romanick]

On 09/15/2016 03:12 PM, Ian Romanick wrote:
> This series makes the stand-alone GLSL compiler useful for something.
> It adds an option to generate C++ code that uses ir_builder to recreate
> the compiled GLSL shader.  I intend to use this for various lowering
> code for GL_ARB_gpu_shader_int64 and GL_ARB_gpu_shader_fp64 (on
> platforms that don't actually have double precision hardware).  See also
> Elie Tournier's "soft double" GSoC project.
> 
> As an example, I present some GLSL code that does 64-bit integer
> division:
> 
> https://people.freedesktop.org/~idr/udivmod64.glsl
> 
> and the C++ code generated:
> 
> https://people.freedesktop.org/~idr/udivmod64.cpp
> 
> This is a little bit of fib... the code in this series lacks a very
> small amount of 64-bit integer support, and the other necessary bits in
> Mesa are not yet in master.  A tree with all of that will be available
> soon.

https://cgit.freedesktop.org/~idr/mesa/log/?h=arb_gpu_shader_int64

radeonsi uses LLVM to do the 64-bit multiply and division lowering, so
ARB_gpu_shader_int64 support could land before this series.  The
rearranging and rebasing should be trivial to make that work.

> The generated code is only ~200 lines compared to ~50 lines of GLSL.
> However, I can make changes to the GLSL much easier than I can the big
> pile of ir_builder code.  It's a bit like coding in assembly.
> 
> I believe this same technique could be adapted to generate NIR builder
> too.  Then we could use the same GLSL source to lower things in NIR that
> originated from SPIR-V binaries.
> 
> The ideal work flow would be generate the C++ code while Mesa is
> building, like we do with the various lexers and parsers.  However, this
> presents the usual compiler bootstrap problems that we have managed to
> avoid all these years.  It also adds problems for cross-compiling Mesa.
> 
> I don't expect the generated code to change very often... maybe the best
> work flow that will actually work is to generate the C++ files by hand
> and commit both the C++ and the GLSL to the tree.  That seems pretty
> awful, but I'm not sure what we can do that's better.
> 
> One other change I've thought about making... the C++ can include an
> embedded version of the GLSL, possibly as a comment.  Then we could
> detect when the C++ and GLSL didn't match.
> 
> This does feel a little like "everything old is new again."  We used to
> do something similar very early in the compiler development.  We had a
> special inline "assembly" mode, and we'd embed the GLSL for built-in
> functions in the Mesa binary.  At context creation, we'd bootstrap the
> compiler by compiling the built-in functions.
> 
> This series is available at:
> 
> https://cgit.freedesktop.org/~idr/mesa/log/?h=standalone-ir_builder
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>