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