[Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa

[Marek Olšák]

On Mon, Aug 18, 2014 at 7:05 PM, Connor Abbott <cwabbott0 at gmail.com> wrote:
> On Mon, Aug 18, 2014 at 12:38 PM, Ilia Mirkin <imirkin at 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