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

Jason Ekstrand jason at jlekstrand.net
Mon Nov 2 11:41:42 PST 2015


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.


More information about the mesa-dev mailing list