[Mesa-dev] R600g LLVM shader backend

[Tom Stellard]

On Thu, 2011-12-15 at 10:41 -0800, Jose Fonseca wrote:
> ----- Original Message -----
> > On Mon, 2011-12-12 at 07:05 -0800, Jose Fonseca wrote:
> > > ----- Original Message -----
> > > > Hi,
> > > > 
> > > > I have just pushed a branch containing an LLVM shader backend for
> > > > r600g to my
> > > > personal git repo:
> > > > 
> > > > http://cgit.freedesktop.org/~tstellar/mesa/ r600g-llvm-shader
> > > 
> > > Hi Tom,
> > > 
> > > This is pretty cool stuff.  The fact that you have a similar
> > > passing rate to the existing compiler makes it quite remarkable.
> > >  I was aware of several closed/open-source projects to develop GPU
> > > backends for LLVM, and LunarG made a middle end, but this is the
> > > first working OpenGL stack based on a LLVM GPU backend that I'm
> > > aware.
> > > 
> > > > There are three main components to this branch:
> > > > 
> > > > 1. A TGSI->LLVM converter (commit
> > > > ec9bb644cf7dde055c6c3ee5b8890a2d367337e5)
> > > >
> > > > The goal of this converter is to give all gallium drivers a
> > > > convenient
> > > > way to convert from TGSI to LLVM.  The interface is still
> > > > evolving,
> > > > and I'm interested in getting some feedback for it.
> > > 
> > > The interface looks a good start, but I'd like it to be even more
> > > overridable.  I don't even think there's anything GPU specific
> > > there -- I also had some plans to do TGSI translation in llvmpipe
> > > in two stages: first TGSI -> high-level LLVM IR w/ custom
> > > gallivm/tgsi intrinsics -> low-level LLVM IR w/ x86 SIMD
> > > instrinsincs, to allow optimizations and other decisions to happen
> > > at a higher level, before starting to emit lower-level code.
> > > 
> > What else would you like to see overridable?
> 
> I'd like that all LLVM -> TGSI translators (your new one, llvmpipe's TGSI -> aos, llvmpipe's TGSI -> SOA) shared a common hierarchy, so all the things they do different needs to be "pluggable" / overridable. But I'd need to look in more detail to give a precise list.
> 

Ok, this makes sense.  I think the important things to have be plugable
are load and stores to special register files (i.e everything besides
TGSI_FILE_TEMPORARY) and also the conversion of each TGSI_OPCODE to llvm
IR.

> > I think it might be nice to map TGSI opcodes to C functions rather
> > than
> > intrinsic strings.
> 
> What do you mean by "C functions"?
>  

What I meant was instead of passing an intrinsic to the TGSI -> LLVM
converter as a char * and saying convert TGSI_OPCODE_* to this
intrinsic, we should pass function pointers, that get called for each
TGSI_OPCODE_* conversion.


> > > So I'd like us to have a flexible hierarchy of TGSI translators
> > > that can be shared for GPU/CPUs alike.
> > > 
> > > BTW, I'd prefer that all reusable Gallium+LLVM code (be it meant
> > > for GPU or CPU) lives in src/gallium/auxiliary/gallivm , as it
> > > make code maintenance and build integration simpler.  So
> > > tgsi_llvm.c should be moved into gallivm.  Also, beware that the
> > > ability to build core gallium/mesa without LLVM must be preserved.
> > > (Having particular drivers to have hard dependencies on LLVM is of
> > > course at discretion of drivers developers though.)
> > > 
> > > > 2. Changes to gallivm so that code can be shared between it and
> > > > the TGSI->LLVM converter.  These changes are attached, please
> > > > review.
> > > 
> > > I'll review them separately.
> > >
> 
> Been busy days. Still no time to go through them in detail...
>  
> > > Also, maybe it would make sense to have amdil backend distributed
> > > separately from mesa, as it looks like a component that has other
> > > consumers beyond mesa/gallium/r600g, right?
> > > 
> > 
> > Eventually, the AMDIL backend will be distributed as a part of llvm
> > [1],
> > but we still have a lot of work to do to make that happen.  The r600g
> > backend is basically a subclass of the AMDIL backend, so if the AMDIL
> > backend is in LLVM the r600g backend would probably have to be too.
> 
> I think it must be possible to have LLVM backends / passes out of the tree. Anyway, it is a detail.
> 
> > > Why is the result code worse: due to limitations in the assembler,
> > > in the AMDIL LLVM backend, or in LLVM itself?
> > > 
> > 
> > I guess it's due to limitations in the assembler.  When the code is
> > translated from TGSI, the vector instructions fit much better into
> > the
> > VLIW architecture, so the lack of a proper assembler is not as
> > noticeable, but the r600g LLVM backend assumes non-VLIW hardware,
> > which
> > makes the lack of a good assembler really noticeable.
> 
> I see.
> 
> > > What are the state trackers that you envision this will use? (e.g.,
> > > Are you targeting clover? do you hope this will be the default
> > > compiler backend for Mesa? Or is Mesa/Gallium just a way to test
> > > AMDIL backend?)
> > > 
> > 
> > For r600g we are targeting clover, but future chip generations will
> > use
> > LLVM for all state trackers.
> 
> That sounds great!
> 
> > > I'm also interested in your general opinion on using LLVM for GPU.
> > > 
> >
> > The thing that was most difficult for me to model with LLVM was
> > preloading values (e.g. shader inputs) into registers.  I had to try
> > a
> > few different ways of implementing this before I got it to work.
> 
> For curiosity, how did you solve this in the end? Function parameters?
> 

Function parameters are a good idea.  I never thought of that.  

What I did was define intrinsics to simulate pre-loading values into
hardware registers.  The intrinsic for loading inputs looks like this:

f32 r600.load.input(i32) 

So %0 = r600.load.input(0) would be lowered to MOV %0, R0, and then I
would move this instruction to the beginning of the program as a way to
simulate pre-loading.  Not very elegant, but it mostly worked.

However, in the mean time Vadim Girlin has come up with a much better
solution that adds pre-loaded registers to the Live In lists of their
basic block.

-Tom

> >  There
> > are also some features missing from tablegen (the language for
> > defining
> > hw instructions and registers) like having instructions with
> > registers
> > _or_ float immediate arguments that made it a little difficult.
> > Otherwise, the implementation went pretty smoothly.  I think LLVM is
> > flexible enough to be used for GPUs, and is certainly a much better
> > starting point than trying to write a compiler from scratch.
> 
> That's good to hear. LLVM was pretty close to perfect for software rendering on CPU, but GPU presented different challenges.
> 
> LLVM definitely seems to pick more and more momentum lately, and it looks like there's a lot of synergy to be exploiting by leveraging it.
> 
> Jose
>