Zack Rusin wrote: > 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.
OK. What I would suggest is to make this the first goal, ie code-generate the Mesa IR, then use the lessons from that to feed into follow-on work to code-generate i965 programs. Not that I'm saying to stop what you're doing - carry on as you like, but this is probably the way I'm going to investigate things. Keith ------------------------------------------------------------------------- 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
