[Mesa-dev] R600g LLVM shader backend

[Jose Fonseca]

----- 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.

> I think it might be nice to map TGSI opcodes to C functions rather
> than
> intrinsic strings.

What do you mean by "C functions"?
 
> > 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?

>  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