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

[Connor Abbott]

On Mon, Aug 18, 2014 at 1:38 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 18.08.2014 19:05, schrieb 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
>
> I guess having the "typical" gpu features (vec4 representation along
> with swizzles, writemasks, modifiers) in the IR is nice, though I'm
> beginning to wonder if it's all that useful. Obviously, it maps really
> well to "old" gpus (like r300) and old-style shaders using lots of vec4
> (the human-readable assembly is going to be much nicer if you have vec4
> support) but ultimately it seems most newer archs are scalar (or rather,
> their vectors are not along the instruction level axis). Something like
> Mali gpus being an exception rather than the norm. Even things like r600
> need to do their own vliw-ication anyway.

Right... I expect there will be a pass that lowers swizzles and
writemasks for scalar backends, and then you can do another
optimization pass to take advantage of that. There will also be
separate passes for lowering variables for scalar and vector backends
(actually, for now only the scalar one has been written) so that
scalar backends can have things packed more tightly, which seems to be
a pain point with Gallium/TGSI now since it forces your driver to
think in terms of vec4 slots even when your hardware really thinks in
terms of float/32-bit int slots. Even then, in that case it might be
worth it to do some optimizations on the vector representation first
since it's more compact so there should be less instructions and, in
theory at least, the optimizations should be faster from having to do
less work. And at least with mobile GPU's, I think vec4 still seems to
be pretty prevalent (you already mentioned the Mali, and also iirc
PowerVR uses a vector ISA as well).

> In any case, for gallium I'm pretty indifferent to shader IR actually,
> as long as things keep working... Just keep in mind though while tgsi
> might not be the optimal solution, there's significant precedence for
> this kind of low level shader language (since even d3d10 follows that
> model, though I can't tell how happy the IHVs are with it...). But if
> NIR benefits glsl compiler on its own that looks all good to me, it's
> just an area I'm not really familiar with.
>
> btw do you have some example of how a shader looks printed out? I'm too
> lazy to play with it myself...

Sorry, I seem to be unable to get Mesa to build right now so I can't
get it to print some shaders but the syntax is pretty straightforward.

>
> Roland
>