On Sun, Sep 28, 2008 at 8:46 PM, Zack Rusin <[EMAIL PROTECTED]> wrote: > On Sunday 28 September 2008 14:34:53 Stephane Marchesin wrote: >> Hi, >> >> I'm working on llvm integration in gallium, > > Ah, that's great. > >> but I have a small problem >> with the current design. Basically, the tgsi to llvm translator >> currently generates calls to library functions (abs(), exp(), log(), >> ...) at translation time, and now I want to be able to regarget llvm >> to GPUs. > > Yea, that's not its design, just an implementation bug :) > The design is that gallivm_ir was supposed to be completely target > independent. During the gallivm_ir_compile call we wanted to have a hook that > allows the driver to figure out how the target-independent representation is > handled.
Ok, I'm going to do this then. > >> As you can imagine library calls won't work on a GPU, so I >> think I'm going to change the tgsi to llvm translator to generate new >> ops for what used to be library calls (i.e. for all the call* methods >> of the Instructions class) and then have the gallium_cpu turn those >> new ops into calls. >> Does anyone object that ? > > No! That's exactly how it was always supposed to work =) The gallivm_ir was > supposed to be populated with just tokens that were then either lowered or > used as intrinsics (as required by the driver). (In general I think it might > be easiest to treat all tgsi opcodes as intrinsics since that would make it > easier to handle them. Maybe just add some helper function to lower some of > them, e.g. driver could request to automatically lower 'lit' instead of > treating is as an opcode). Oh, I'm thinking about doing driver-specific llvm backends here. I've realised that the difference between GPUs really didn't allow common intermediate representation. Furthermore, the llvm tablegen format is very powerful and I don't think it'll be much more work. So basically instead of doing TGSI -> LLVM -> TGSI -> driver I think we should be doing TGSI -> LLVM -> driver That way we'd allow things like support for both vector (r300, nv30/40, sse...) backends and scalar (nv50, x87 ...) backends. Otherwise the scalar backends have to lower the vectors into scalars at the last minute and this could be suboptimal. I also want to support fixed pipe that way, by describing the fixed pipe functionality in llvm DAGs and letting the DAG matcher from llvm do the actual work. This is a cleaner approach to fixed pipe in gallium than what I tried before. Stephane ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
