[Mesa-dev] R600g LLVM shader backend

[Tom Stellard]

Hi Jose,


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

I'm in the process of reworking the TGSI->LLVM interface right now to
make it a little more flexible, so there is no need for you to review
the old version.  I'll mail the list when the updated interface is ready
for review.

-Tom