[Mesa-dev] Call i965 GLSL IR backend optimisation from the common linker
timothy.arceri at collabora.com
Wed Jul 27 06:18:28 UTC 2016
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
> > 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,
> 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
More information about the mesa-dev