vc4: Lazily emit our FS/VS input loads.
authorEric Anholt <eric@anholt.net>
Fri, 24 Feb 2017 20:57:03 +0000 (12:57 -0800)
committerEric Anholt <eric@anholt.net>
Sat, 25 Feb 2017 01:01:29 +0000 (17:01 -0800)
commit292c24ddac5acc35676424f05291c101fcd47b3e
tree1cc326dc2c1dd5c8abd664dae0b4e1fcfa4bf373
parentf06915d7b71eb955cc0db4b5555f5c6474926a01
vc4: Lazily emit our FS/VS input loads.

This reduces register pressure in both types of shaders, by reordering the
input loads from the var->data.driver_location order to whatever order
they appear first in the NIR shader.  These instructions aren't
reorderable at our QIR scheduling level because the FS takes two in
lockstep to do an interpolation, and the VS takes multiple read
instructions in a row to get a whole vec4-level attribute read.

shader-db impact:
total instructions in shared programs: 76666 -> 76590 (-0.10%)
instructions in affected programs:     42945 -> 42869 (-0.18%)
total max temps in shared programs: 9395 -> 9208 (-1.99%)
max temps in affected programs:     2951 -> 2764 (-6.34%)

Some programs get their max temps hurt, depending on the order that the
load_input intrinsics appear, because we end up being unable to copy
propagate an older VPM read into its only use.
src/gallium/drivers/vc4/vc4_context.h
src/gallium/drivers/vc4/vc4_draw.c
src/gallium/drivers/vc4/vc4_program.c
src/gallium/drivers/vc4/vc4_qir.h