Zack Rusin wrote: > On Thursday 17 May 2007 05:36:45 pm Keith Whitwell wrote: >>>> I think the Zack/Roberto LLVM tree has done just this. Unfortunately >>>> for this immediate problem, they target a whole new intermediate >>>> representation. >>> Zack, what tools did you use for the front-end/parser? I've been >>> looking over LLVM but I haven't seen any sign of a parser generator. > > Yeah, that's where Roberto came in :) We used QLALR which is simply amazing > and for those who ever used Bison a lot more convenient than what we had > right now. > > http://labs.trolltech.com/page/Projects/Compilers/QLALR > > Initially we used QLALR with Flex, then we just went only with QLALR (Flex is > really bad when its come to its usage in libraries and there was no real > reason for it). If you ever used yacc then you can use qlalr right away. > QLALR generated files are simply so much better it was just worth it. I think > Roberto could write a book about why QLALR just rocks and it makes sense to > use it in this case (granted that the book would have limited audience and > I'll let him do that once his back) rather than anything else. > >> In fact I think they've used Roberto's QLALR compiler-generator, which >> in itself raises some issues about licensing. >> >> QLALR is GPL'ed, what is the GPL-status of the sources it generates?? > > Technically I think by default they inherit the license of the grammar. Now > having said that, it's of course up to developer to decide what is the > license of the grammar. We'll license everything under the same standard Mesa > MIT license. > But yeah, the glsl.g grammar that we have there is extremely good, Roberto > did > a wonderful job and imho it would just make sense to use it with or without > LLVM (of course I do love that code so I am very biased).
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. - 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. 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 thinking for this is: 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. 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. 3) As noted above, we need to get to the mesa IR somehow for other devices. 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
