Bringing GLSL to the masses (the glsl2 project for Mesa OpenGL) скачать в хорошем качестве

Bringing GLSL to the masses (the glsl2 project for Mesa OpenGL)

Presenter(s): Eric Anholt URL: http://2011.linux.conf.au/programme/s... This presentation will cover the new OpenGL GLSL compiler for Mesa that I have been developing with Ian Romanick and Ken Graunke at Intel. Mesa's previous compiler was primitive, parsing something resembling GLSL and emitting directly to an abstract assembly language, with the most minimal of optimization in between. We started over by pulling out the compiler textbooks, and in 4 months have produced a compiler for OpenGL on Linux that's regularly producing 2/3 the instructions of the previous one, and able to support GLSL shaders on a wider variety of hardware than was previously allowed, which will in turn let the user experience developers produce a shinier desktop environment without leaving people on old hardware in the dust. Along the way, we've found that while compiler textbooks are useful, many of the techniques are tricky to apply to vector machines. SSA and value numbering are of limited use, since so many operations update a subset of a vector variable's componenets. If you split each component out as its own value to track, you risk being inefficient in recombining to vector operations. When you've only got 64 vector instructions available to run on older hardware, that's a dangerous game to play. On the other hand, real-world shader programs we see are filled with opportunities to take advantage of algebraic simplification to reduce computation. While most compilers are concerned with the compile-time/run-time performance tradeoffs, GL compilers know that every line of code is going to be executed thousands or millions of times per second, and arbitrary amounts of computation up front can be thrown at improving the performance of shader programs. And finally, there are some serious issues with trying to run GLSL code on common older hardware that wasn't designed for it. Most other vendors have decided to take the route we have, which is "Support 95%, and tell the application developer when they did something we couldn't support." You get only around 64 arithmetic instructions, 20 or so live vector values, and some mystic instruction ordering requirements. Dynamic branching doesn't actually exist, and has to be faked with loop unrolling and conditional moves, and a do-or-die attitude toward function call inlining. Old hardware adds up to a fun challenge and a good test of your compiler infrastructure. http://2011.linux.conf.au/ - http://www.linux.org.au CC BY-SA - http://creativecommons.org/licenses/b...