[Mesa-dev] Unused (?) duplicated GLSL IR state in NIR

[Connor Abbott]

On Tue, Nov 3, 2015 at 5:08 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 2 November 2015 at 19:41, Jason Ekstrand <jason at jlekstrand.net> wrote:
>> On Mon, Nov 2, 2015 at 9:33 AM, Connor Abbott <cwabbott0 at gmail.com> wrote:
>>> On Mon, Nov 2, 2015 at 8:35 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> From a quick look, it seems that NIR copies (almost ?) all the state
>>>> from GLSL IR even if it doesn't use it.
>>>>
>>>> The particular piece that I'm thinking about is nir_variable::data.
>>>> Afaict this is a remnant from the early days, when the intent was to
>>>> kill off the GLSL IR and use NIR directly. If so should we just nuke
>>>> it, or (if there is someone working on it) add some comments "Keepme:
>>>> WIP work by XXX to use this and kill the glsl IR one".
>>>>
>>>> The (not that distant) GLSL IR memory optimisations by Ian, seems to
>>>> have missed NIR. Was that intentional or were those worked upon before
>>>> NIR got merged ? Perhaps it's worth porting them over ?
>>>>
>>>>
>>>> Thanks
>>>> Emil
>>>> _______________________________________________
>>>> mesa-dev mailing list
>>>> mesa-dev at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>
>>> Hi Emil,
>>>
>>> Indeed, nir_variable was copied from ir_variable before Ian's memory
>>> optimizations landed. Also, as you noticed, there are a number of
>>> fields only used by the GLSL linker, so they're unused until/unless we
>>> do linking in NIR. I wouldn't be opposed to nuking those, since we can
>>> always revert the commit if/when we get to that.
>>
>> Agreed.  If you want to nuke some of them, feel free to send the
>> patch.  If you do, please CC me.  There are some things that we're
>> using for SPIR-V so I might request that you keep a field or two.
>> However, cleaning it up would definitely be a good idea.
>>
>> One thing I will note though is that you should consider this a
>> cleanup and not an optimization.  The reason why Ian's stuff helped
>> GLSL IR so much is that it uses variables extensively.  The average
>> NIR shader only has about half a dozen variables by the time you get
>> done optimizing so it's not nearly as much of a problem.
> Ack. Thanks guys. So currently no-one is pursuing move the linking to NIR ?

No, not currently, since first it requires a lot of optimization
passes that GLSL IR has but not NIR to be translated to NIR (loop
unrolling, function inlining, tree balancing etc.) before it's both
possible and not a regression.

>
> On the optimisation vs cleanup note - it'll be tiny bit of both.
>
> -Emil