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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev