On Sat, Nov 12, 2016 at 5:29 PM, Thomas Helland <thomashellan...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
