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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
