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. 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. z ------------------------------------------------------------------------------ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
