On Fri, 2009-07-24 at 10:54 -0700, Zack Rusin wrote: > On Friday 24 July 2009 13:33:22 José Fonseca wrote: > > > To be honest I don't think that using LLVM from C for our purposes is a > > > good idea. Mainly because it will be impossible to do because backends > > > (the actual code-generators for given hardware) will need to be C++ > > > anyway so we'll again end up with a mix of C++ and C. It's just that the > > > interface from C++ is a lot nicer than the stuff that was wrapped in C. > > > > I understand that the C bindings might be more cumbersome and limited. > > But I don't understand how using or not avoids the mixing C and C++: if > > LLVM is in C++ and Gallium is in C something will have to make brigde. > > It is a matter of what and how thick that bridge is. > > Yea, gallivm is that bridge. It's compiled with C++, but exposes a C > interface > to the rest of Gallium. This is essentially to make all Gallium interfaces > uniformly C (plus to hide a lot of LLVM complexity). > > Of course it's still impossible to write fully-fledged LLVM driver without > C++, > as the code-generator will have to be in C++. (that code-generator could > technically be a separate module, in fact living in a repository of its own > though). > > But the short-term scenario that we're looking at right now is not: > TGSI->LLVM->Hardware > it's > LLVM->TGSI->Hardware.
I'm actually more interested in the former, and that was what I had in mind so far. > That's what OpenCL will be doing and that's what we want to do for GLSL as > well. > So the idea is that the OpenCL compiler compiles C into LLVM IR and the GLSL > compiler compiles GLSL into LLVM, then we run all the LLVM optimization > passes > on that and then gallivm translates LLVM IR into TGSI. > The benefit of this approach is that our drivers keep working as they did, > code-generation is still trivial, we still get LLVM optimizations and our > interface is uniformly C everywhere. > > So that'd be step 1 and step 2 would be experiment with direct hardware > generation from LLVM, but thanks to this approach our biggest woe (lack of > decent optimization framework for the more and more complicated shaders that > we're seeing) goes away without modifications to the drivers at all which I > think is fairly neat. Yes, it seems a good stepping stone. But in this step 1 you don't plan to embed the vector width and AoS vs Soa in TGSI, right? Jose ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
