[Mesa-dev] [PATCH 0/2][RFC] Rework how glsl runs optimization passes

[Matt Turner]

On Sat, Nov 12, 2016 at 5:29 PM, Thomas Helland
<thomashelland90 at gmail.com> wrote:
> After looking into how optimization passes are run, it became apparent
> that most glsl optimization passes only show benefit of one run.
> My idea was that some optimization passes will snowball on each other,
> while others that provide no initial benefit probably never will.
> Therefore, rework so that passes that only passes that made progress
> will be rerun, while the rest will get dropped.

That's not a sound theory.

> I'm not perfectly happy with the hack of passing the index into the
> optimization macro, and I'm considering other ways of solving this.
> An enum of sorts might be a possibility. This is probably also not
> the most ideal way of reducing runs of compiler passes. A carefully
> though out order of passes that is run only once (like LLVM does)
> is  probably better, but that would be more involved.
>
> There are no piglit regresions, and shader-db shows no changes for
> fills, spills, loops, or instruction count. However, cycle count shows
> a ridiculous improvement:
>
> total cycles in shared programs: 1344569689 -> 90702114 (-93.25%)
> cycles in affected programs: 1334668075 -> 80800500 (-93.95%)
> helped: 229
> HURT: 375
>
> It seems to be mostly shaders that either regress massively,
> or improve massively. One example that shows this behavioy is:
>
> ./shaders/glamor/74.shader_test FS SIMD8:    104 -> 65586 (62963.46%)
>
> So I'm not sure if these results are thustworthy.

No, all this indicates is that things are broken.

> Thoughts on the aproach are welcome. This is more of a suggestion
> than anything, as there is probably differing ideas about this.

Completing Tim's work on NIR optimizations during linking seems like
the right way forward to me.