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

[Alex Deucher]

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.
> 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.

FWIW, we use AMDIL internally:
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/AMD_Intermediate_Language_(IL)_Specification_v2.pdf
http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/documentation/amd-app-documentation/

Alex

>
> btw do you have some example of how a shader looks printed out? I'm too
> lazy to play with it myself...
>
> Roland
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev