On Tuesday 15 May 2007 06:29:43 am Keith Whitwell wrote: > Of particular interest to us is the runtime code generator and shader > compiler. We have been developing something we're calling the "Tungsten > Graphics Shader Infrastructure", which is intended to be a retargetable > compiler for GLSL and similar high level shading languages, anchored > around shared intermediate representations and a common optimization > framework. I should be able to thow some documents up on the web soon > to throw a bit of light on this.
Hmm, I really hate to mention this for the first time like this but I think it's better if people know and Roberto and I will just announce it properly later. I have been toying around with writing a proper shading infrastructure for Mesa for a while now. Finally I managed to convince Roberto to help me with it and we started. Both of us work on it in the spare-time-of-a-spare-time and I wanted to wait with announcing it until we have proper benchmarks and one of the drivers done but here's the bottom line: we're bringing LLVM in Mesa. http://llvm.org So first of all why. - Because we won't be able to write a compiler infrastructure that is even close to it and we just won't get to a point where we can perform the same optimizations that LLVM does right now. - Because even if we'll decide to start taking code from LLVM and porting it to our new framework we won't have resources to maintain the kind of optimization passes that are needed by modern systems. - Because we're graphics people (well, I'm more a super-model myself and Roberto is a compiler genius, so I guess what I'm saying is "you") and it would be nice if we could do graphics and leave compilers to the compiler people. - Because LLVM has a great IR and everything we'll pretty much need already. - Because it would make Mesa code a lot cleaner (graphics code and no compiler infrastructure in a graphics project sounds pretty sensible to me). - Because it trivially allows us to bind many more languages than just GLSL. - Because LLVM is simply amazing. So what do we want do/did (besides looking awfully cool, which I do 24/7 and Roberto 24/6 - the one day he reserves for being a compiler genius and you can't look cool while being a compiler genius). Roberto wrote this wickedly awesome GLSL parser (simple enough) and from our AST we create LLVM structure and simply enough in the software cases that structure will just be fed to LLVM jit and executed. Hardware case is way more fun, for the hardware case I'm just writing a lowering pass. So in the hardware case after constructing LLVM representation of the program we'll run the lowering pass over it. During the lowering pass the driver can decide what is being lowered and what is no. E.g. driver could say "oh, i support trigonometric builtins of GLSL so don't lower sin/cos, etc.". The same principle can be applied to any of the builtins to not have them lowered. By default (the software case) everything is being lowered. After the lowering pass is done, LLVM optimization passes will be run to, well optimize the freaking crap out of what's there. Once that's done the driver provided code generator (which is just a normal LLVM code-generator) is fed the IR to generate the driver specific instructions and that's it. Now, what does that mean: - it means that Mesa gets the most comprehensive shading framework out there, and it gets it now not some time in the future, - it means that we get insane optimization passes for free (strong emphasis on "insane". They're so cool I drool about being able to execute shading languages with this framework and I drool very rarely nowadays... Honestly) - it means we get well documented and understood IR, - it means we get maintenance of part of the code we're really not terribly good at (besides Roberto of course) for free, - it means that there's less code in Mesa, - it means that adding new driver specific code becomes pretty simple: 1) decide what to lower for your hardware, 2) write LLVM code generator - which is well documented and fairly simple (assuming you know the hardware of course, which still involves one of those "brain" things but those "brain" things can come without a "phd in compiler construction" tattooed on a side) - it means that we can basically for free add execution of C/C++, soon Python, Java and likely other languages, code on GPU's because frontend's for those are already available/"in work" for LLVM. (and even though I'm not a big fan of Python the idea of executing it on GPU is giving me goose-bumps the way only some of Japanase horror movies can) So those would be the pros. The cons would involve : - me drooling a lot whenever someone mentions Mesa/LLVM shading infrastructure, - C++ code in Mesa (not to me but I'm in general pretty agnostic, both religiously and technically and I tend to like sound technical arguments in both.) LLVM is written and use beautiful C++ and currently I wrap it so that the external interface is C only anyway so I hope it's not going to cause a religious fallout. - removal of the code you guys put a lot of time and effort in. Now having said I have a git repo at: http://gitweb.freedesktop.org/?p=users/zack/mesa.git;a=shortlog;h=llvm but I haven't push a few of my local changes and I haven't pulled from Roberto for a while as well. Roberto is working on finishing up the AST->LLVM code, we need arb_fragment/vertex_program->LLVM code, I need to finish the lowering pass and also so far I just didn't have motivation to figure out how i965 instruction set works like, especially that I don't even have one, but once those are ready we will be basically done. So we're getting there and the question becomes whether Mesa/LLVM shading framework is the best possible choice for Mesa - Roberto and I certainly think so and I'm sure LLVM guys would agree. 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
