Brian Paul wrote: > 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. > > It looks like conditional branches in the LLVM IR are somewhat > structured. From http://llvm.org/docs/LangRef.html#terminators > > Test: > %cond = icmp eq, i32 %a, %b > br i1 %cond, label %IfEqual, label %IfUnequal > IfEqual: > ret i32 1 > IfUnequal: > ret i32 0 > > It might not be too hard to generate IF/ELSE/ENDIF GPU instructions from > that. But if the optimizer changed the structure... hmmm. > > > I was looking at LLVM's vector support a little more. There's basic > vector add, sub, mul, divide and shuffling, but that's about it. > > GPU instruction sets have vector min/max, abs, lrp, dot product, frac > and set-if-less/greater/equal, etc that are commonly used in shader > code. I think it's important that the code generator emits those > instructions, rather than scalar decompositions. > > It seems that either the LLVM IR would need some extensions for those > things or the back-end code generator/instruction selector would have to > look for patterns of scalar instructions and figure out where vector ops > should be used. The later sounds unpleasant.
Yes, approximately 50% of the time, we need to preserve the vector semantics. The other 50% of the time, we need to convert vector operations to scalar ones. In the i965, for instance, vertex programs execute with vector semantics (8-wide registers hold xyzw for two vertices) and fragment programs execute with scalar semantics (16-wide register pairs hold x for 16 pixels -- this is one way to run out of registers quickly). Currently the vector->scalar transition is handled by the driver, it would be interesting to do this at a higher level, but we need to preserve the ability to extract .xyzw-style vector instructions. I've had limited time to look into this, unfortunately. I'm concentrating first on getting the code I've got into some reasonable form to commit. 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
