glsl: Immediately inline built-ins rather than generating calls

Graphics / Mesa 3D Graphics Library / Mesa - Kenneth Graunke [whitecape.org] - 23 September 2016 18:40 UTC

In the past, we imported the prototypes of built-in functions, generated calls to those, and waited until link time to resolve the calls and import the actual code for the built-in functions.

This severely limited our compile-time optimization opportunities: even trivial functions like dot() were represented as function calls. We also had no way of reasoning about those calls; they could have been 1,000 line functions with side-effects for all we knew.

Practically all built-in functions are trivial translations to ir_expression opcodes, so it makes sense to just generate those inline. Since we eventually inline all functions anyway, we may as well just do it for all built-in functions.

There's only one snag: built-in functions that refer to built-in global
variables need those remapped to the variables in the shader being compiled, rather than the ones in the built-in shader. Currently, ftransform() is the only function matching those criteria, so it seemed easier to just make it a special case.

On Skylake:

total instructions in shared programs: 12023491 -> 12024010 (0.00%) instructions in affected programs: 77595 -> 78114 (0.67%) helped: 97 HURT: 309

total cycles in shared programs: 137239044 -> 137295498 (0.04%) cycles in affected programs: 16714026 -> 16770480 (0.34%) helped: 4663 HURT: 4923

while these statistics are in the wrong direction, the number of hurt programs is small (309 / 41282 = 0.75%), and I don't think anything can be done about it. A change like this significantly alters the order in which optimizations are performed.

b04ef3c glsl: Immediately inline built-ins rather than generating calls.
src/compiler/glsl/ast_function.cpp | 46 +++++++++++++++++-------------------
1 file changed, 22 insertions(+), 24 deletions(-)

Upstream: cgit.freedesktop.org

  • Share