[Mesa-dev] [GSoC] Improved application of GLSL complier optimizations

[Matt Turner]

On Tue, Mar 3, 2015 at 11:43 AM, Alexander Mezin
<mezin.alexander at gmail.com> wrote:
> Hello.
>
> I plan to participate in GSoC this year as a student. And I've found a
> project idea which I like very much on X.Org's ideas page. It's called
> "Improved application of GLSL compiler optimizations".
>
> For me, it looks mostly like an optimization problem in mathematical
> meaning. Benchmark could be treated as a function that computes a
> score taking a sequence of passes as input. If I'm not mistaken, there
> are more than 30 passes, so even trying all permutations will take a
> long time, even if we imagine we can measure shader "quality"
> immediately. I think it's worth to try various heuristic optimization
> techniques like simulated annealing or genetic algorithm.
>
> Furthermore, looks like the same pass sequence could give different
> results on different shaders, so it won't be possible to determine
> single optimal sequence. But some limited randomization could help
> dealing with it, probably.
>
> Overall this project looks more like research than coding. I like it,
> but I have few concerns:
> 1. Probably the final result will look very stupid, like "do
> everything twice in any order, everything else doesn't matter". Though
> it will be proved at least.
> 2. What to do next depends on results of the previous step. I'll
> hardly be able to do very detailed plan.
>
> So, do you think it's worth trying?

I don't think this project is very interesting, unfortunately.

There are multiple sets of optimizations that run in loops until they
collectively find some steady state: the GLSL compiler (see
src/glsl/glsl_parser_extras.cpp::do_common_optimization), the NIR
level for some drivers (see
src/mesa/drivers/dri/i965/brw_fs_nir.cpp::nir_optimize), and the
driver backend optimizations (see
src/mesa/drivers/dri/i965/brw_fs.cpp::fs_visitor::optimize for
example).

Different orderings of the GLSL compiler's optimizations just leads to
madness. Reordering causes all sorts of unexpected differences and
really the IR is not good for optimizing to begin with. We want to
stop doing optimizations there, really.

NIR is a better IR for optimizing. There is maybe something to be
learned by reordering optimizations there... I'm not sure. One thing
that we do know already is that we don't have all of the optimizations
in place that we want -- global value numbering is missing for
instance. It shouldn't be hard to add, but no one's done it.
Reordering optimizations in NIR probably isn't interesting at this
point.

Speaking for i965 here, since that's the driver I work on --

Kind of like NIR, we expect we can get much bigger gains by improving
existing optimizations rather than figuring out a different ordering.
We'd like to implement SSA in the i965/fs (struct-of-arrays) backend
and an SSA-based register allocator. That might be a good summer of
code project.

But that's more coding than research (the research having been done
~10 years ago), so it might not be interesting to you.

So really I don't think we want to improve the "application" of
optimizations but rather simply improve the optimizations themselves.

If you are interested in working on compiler optimizations, let us know.