On Mon, Aug 18, 2014 at 7:05 PM, Connor Abbott <cwabbo...@gmail.com> wrote: > On Mon, Aug 18, 2014 at 12:38 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> Looking at it another way, perhaps we should just accept that backends >> will want to do their own things, and try to minimize the damage by >> doing >> >> GLSL IR -> transport ir -> backend >> >> Are you envisioning a world where every backend uses NIR, and uses >> some sort of shared register allocation/spilling/etc logic, >> configurable instruction lists, pluggable with lowering passes? By >> then you've invented LLVM... >> >> -ilia > > No, I expect that backends will still want to do their own register > allocation/spilling/scheduling etc. - and besides for that, NIR > supports structured control flow, swizzles and writemasks, modifiers > (abs, negate, saturate), etc. natively in the IR instead of something > that's tacked on or something that drivers have to do themselves. So > no, I'm not re-inventing LLVM. On the other hand, it's entirely > possible for backends to add their own backend-specific opcodes and > intrinsics, and thereby be able to do some amount of lowering and > optimization in NIR. Another reason that backends might want to accept > NIR is so that they can give NIR passes more precise information on > e.g. when to do if-conversion. Again, this is all speculative though - > we'll have to do more of the work before we can find out how we want > to use NIR beyond what originally wrote it to be, which was a way to > do common optimizations that we couldn't do in GLSL IR.
This sounds good. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
