[Mesa-dev] Unused (?) duplicated GLSL IR state in NIR
Jason Ekstrand
jason at jlekstrand.net
Tue Nov 3 08:41:16 PST 2015
On Tue, Nov 3, 2015 at 2: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 ?
I have no plans to do full-blown GLSL-style linking in NIR. Those
linking rules are nuts and that's what we have a GLSL compiler for.
If we do any linking in NIR, it'll be much simpler. Like I said,
delete at will and, if I want you to keep anything, I'll say so when
you send the patches.
--Jason
> On the optimisation vs cleanup note - it'll be tiny bit of both.
>
> -Emil
More information about the mesa-dev
mailing list