On Mon, Oct 18, 2010 at 9:18 AM, Jerome Glisse <j.gli...@gmail.com> wrote: > On Fri, Oct 15, 2010 at 7:44 PM, John Kessenich <jo...@lunarg.com> wrote: >> Hi, >> LunarG has decided to work on an open source, long-term, highly-functional, >> and modular shader and kernel compiler stack. Attached is our high-level >> proposal for this compiler architecture (LunarGLASS). We would like to >> solicit feedback from the open source community on doing this. >> I have read several posts here where it seems the time has come for >> something like this, and in that spirit, I hope this is consistent with the >> desire and direction many contributors to this list have already alluded to. >> Perhaps the biggest point of the proposal is to standardize on LLVM as an >> intermediate representation. This is actually done at two levels within the >> proposal; one at a high-level IR close to the source language and one at a >> low-level IR close to the target architecture. The full picture is in the >> attached document. >> Based on feedback to this proposal, our next step is to more precisely >> define the two forms of LLVM IR. >> Please let me know if you have any trouble reading the attached, or any >> questions, or any feedback regarding the proposal. >> Thanks, >> JohnK > > > Just a quick reply (i won't have carefully read through this proposition > before > couple weeks) last time i check LLVM didn't seemed to fit the bill for GPU, > newer GPU can be seen as close to scalar but not completely, there are > restriction on instruction packing and the amount of data computation > unit of gpu can access per cycle, also register allocation is different > from normal CPU, you don't wan to do register peeling on GPU. So from > my POV instruction scheduling & packing and register allocation are > interlace process (where you store variable impact instruction packing). > Also on newer gpu it makes sense to use a mixed scalar/vector representation > to preserve things like dot product. Last loop, jump, function have kind > of unsual restriction unlike any CPU (thought i haven't broad CPU knowledge) > > Bottom line is i don't think LLVM is anywhere near what would help us.
I think this is the big question mark with this proposal -- basically can it be done? I believe John feels the answer to that is yes, it can, with some work. From my point of view, I think I need to actually see it - but it sounds like this is what John is saying they're going to do. At a high level, LLVM is very compelling - there's a lot of work going on for it, a lot of people enhancing it, etc. Now, if it's possible to leverage that for shader compilation, I think that's very interesting. So basically I think it's necessary to figure out what would constitute evidence that LLVM is capable of doing the job, and make getting to that point a priority. If it can't be done, we'll find out quickly, if it can then we can stop debating whether or not it's possible. Keith _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
