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

[Connor Abbott]

On Mon, Aug 18, 2014 at 12:38 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Mon, Aug 18, 2014 at 12:25 PM, Connor Abbott <cwabbott0 at gmail.com> wrote:
>> On Mon, Aug 18, 2014 at 11:47 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
>>> On 18/08/14 14:21, Marek Olšák wrote:
>>> Once these are in place, all development effort to go on to
>>> improving/leveraging the new IR.  We could deprecate TGSI when it would have
>>> few users.
>>
>> Also, switching to LLVM, NIR, or some other IR that uses SSA (or at
>> least modifying TGSI to support it) seems like something that's really
>> necessary for the Gallium folks. Soon, considering most backends
>> already use SSA in one form or another, the situation will look like:
>>
>> GLSL IR -> NIR -> NIR with SSA -> optimizations -> NIR without SSA ->
>> TGSI -> backend without SSA -> backend with SSA
>>
>> So backends would have to duplicate the into-SSA logic and every
>> shader would have to pay the penalty of being converted out of and
>> then back into SSA thanks to TGSI not supporting it.
>
> 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.

Connor