On Friday 18 May 2007 05:07:08 am Keith Whitwell wrote: > Sounds good. > > I've been thinking about LLVM and Mesa a little bit the last few days. > If it can be made to work, it seems like a good way to go. There are a > couple of practical issues that should be taken into account though: > > - Firstly, we need to continue supporting the existing drivers. In > particular this means we need to generate programs they can understand > (ie in the current Mesa IR), up until the point at which they all > understand LLVM.
Hmm, that's a good point. To be honest I haven't really thought about that. > - Secondly, I'm not yet convinced that LLVM in its current state really > can support the wierdnesses of native GPU architectures. There are some > assumptions that seem to be encoded in LLVM that don't apply on GPU's -- > things like the availability of a general branch instruction, for instance. Yeah, I've been stressing over this a little bit as well. It's not so much LLVM IR that stresses me as their optimization passes. LLVM IR is pretty extensible and I thought about simply extending it with if/else constructs - my main conceptual problem is that I was afraid that potentially arbitrary optimization passes could destroy that structure. Currently what I wanted to do is handle it in a separate lowering pass. Meaning that if the hardware doesn't handle branching the lowering pass tries to decompose it to some form of if/else constructs (which is really not lowering but "highering" =) but you get the point). Conceptually it's not rocket science but a question of whether this will work and work well is a whole different issue and hard to answer. > On this second level as well, I feel a lot more comfortable with the > idea of an intermediate step in this project where the LLVM optimizer > targets something like the Mesa IR (or the cleaned up version we have > been working on internally) as its initial output, and then look at > hardware in a second phase. The problem with this is that the optimization passes operate on LLVM IR, and they're transforming passes so technically even though your input maybe didn't have any branches the output might very well have them. So a "highering" pass would need to be run either before or during compilation to Mesa IR. And if we have that pass then translation to Mesa IR doesn't make so much sense as we can have LLVM IR with our intrinsics that the code generators in drivers understand. > 1) The Mesa IR has many of the characteristics of the hardware ISA's, > with supposedly "high level" GPU/SIMD constructs like IF/THEN/ELSE > opcodes as opposed to CPU-world ideas like labels & branches. > Generating this would be a good validation of LLVM for this work. Like I mentioned above that can done by just extending LLVM. It's not really clean but I'm sure we could kung-fu kick LLVM guys to do it properly for us. > 2) The i965 is an intricate device to program, especially without docs > or a simulator/debugger. The register horizontal/vertical stride and > step addressing modes are pretty unique (and confusing), for instance. > Going all the way to hardware seems like a big task to do in a single > development step. The IR->hardware translation will have to happen at some stage anyway. With LLVM passes hardware can at least easily decide what kind of IR it would be most comfortable with so I don't think it would be much harder than with dedicated IR for the given hardware. > 3) As noted above, we need to get to the mesa IR somehow for other devices. That's a good point. But if we're talking about the IR infrastructure that the drivers use right now then that's not a problem. I think that in this case just a general code-generator would suffice. Zack ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
