Mesa "Flatland" GLSL IR Proposal

A new GLSL intermediate representation (IR) approach has been proposed for Mesa in replacing its existing tree-based representation for shaders.

Connor Abbott, the high school student that started out doing low-level, technical work on the reverse-engineered Lima ARM Linux graphics driver has expanded his sights. The young but knowledgeable free software developer last month began working on SSA support for Mesa's GLSL IR and now may rework the GLSL intermediate representation entirely.

Ian Romanick at FOSDEM last week covered Mesa's existing tree-like shader IR spearheaded by the Intel developers in their open-source Linux graphics driver. The presentation slides can be found in PDF form. There's also a WebM video.

Ultimately this intermediate representation needs to be overhauled or replaced entirely, but the next step is what's still up in the air. Connor Abbott has now started a new developers' mailing list thread entitled Flatland.

Connor's proposal includes, "rather than slowly introducing changes across the board, we create the IR in its final form in the beginning, write passes to flatten and unflatten the IR, and then piece-by-piece rewrite the rest of the compiler. We're going to have to rewrite a lot of the passes to support SSA in the first place, so why not convert them to a flat IR while we're at it? The benefit of this is that it's much easier to do asynchronously and in parallel; rather than introducing changes to the entire thing at once, several people can convert this and that pass, the frontend, the linker, etc. independently. It would entail some extra overhead during the transition in the form of the flattening and unflattening passes, but I think it would be worth it for the immediate benefits (optimizations like GVN-GCM and CSE made possible, etc.)."

Pending sufficient interest in the "Flatland" IR approach he's willing to come up with the basic patches to implement his approach.

AMD's Alex Deucher has already come out and suggested just moving to LLVM directly. Using LLVM right now is the Radeon driver with their OpenCL/Compute support and as a shader compiler too while it's also used by the LLVMpipe driver. Nouveau has played with LLVM support too. At past FOSDEMs there's been talk of Intel's Linux GPU driver moving to LLVM but that has yet to materialize and is expected to be a slow and daunting process.

We'll see soon how other developers respond on the Mesa mailing list.