[Mesa-dev] Call i965 GLSL IR backend optimisation from the common linker

[Timothy Arceri]

On Tue, 2016-07-26 at 22:56 -0700, Matt Turner wrote:
> On Tue, Jul 26, 2016 at 10:20 PM, Timothy Arceri
> <timothy.arceri at collabora.com> wrote:
> > The ultimate goal is to be able to convert to NIR and make use of
> > its
> > optimisations before assigning varying and uniform locations. This
> > should allow us to start removing some of the GLSL IR optimisation
> > passes.
> 
> I'm very excited about this!

:)

> 
> > This series falls short of making use of NIR because
> > lower_packed_varyings()
> > modifies the IR after we assign varying locations. I can see two
> > ways
> > around this, listing them in increasing difficultly level they
> > would be:
> > 
> > - replacing the current packing pass with one that follows the
> > packing
> > rules of ARB_enhanced_layouts this would mean we can no longer pack
> > across slots and matrix and array packing effectivness would be
> > slightly
> > decreased.
> > - write a NIR packing pass.
> 
> Specifically a NIR implementation of lower_packed_varyings(), right?

Correct. I should have also mentioned that after assigning the
locations in the GLSL IR linker my current plan would be to insert
these locations into the existing NIR that gets created. I haven't
figured out how I would do this just yet but I'm hoping it can be done
and without being too hacky. Hence why is why we could do option 1 as
we would just be updating component and location fields rather than
altering the IR.

> 
> > 
> > Even without converting to NIR this series solves a number of the
> > other
> > problems with converting to NIR earlier and provides a nice shader-
> > db
> > improvement on its own.
> > 
> > Broadwell shader-db results:
> > 
> > total instructions in shared programs: 8651650 -> 8644415 (-0.08%)
> > instructions in affected programs:     38754 -> 31519 (-18.67%)
> > total loops in shared programs:        2085 -> 2085 (0.00%)
> > helped:                                320
> > HURT:                                  0
> > GAINED:                                0
> 
> Impressive.
> 
> > Ivybridge reported no difference.
> 
> I suspect that's because Ivybridge's vertex shader is vec4, and we
> don't dead code eliminate individual *components* of varyings,
> whereas
> on Broadwell with scalar vertex shaders we're able to eliminate those
> dead components.

Yeah I was wondering why at first I thought I forgot to switch branches
but after looking at the code I assumed this to be the case thanks.

> 
> Thanks so much for working on this!

No problem. I'm happy to let someone else take this further if they
would like to, I just thought I would see how hard it would be to do.

> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev