On Tue, Mar 3, 2015 at 11:43 AM, Alexander Mezin <mezin.alexan...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
