There are never render target reads, so there are no scheduling hazards.
Giving the extra flexibility to the scheduler makes it possible to do
FB writes as soon as their sources are available, reducing register
pressure. It also makes it possible to do the payload setup for more
than one FB write message at a time, which could better hide latency.
shader-db results on Skylake:
total instructions in shared programs:
9110254 ->
9110211 (-0.00%)
instructions in affected programs: 2898 -> 2855 (-1.48%)
helped: 3
HURT: 0
LOST: 0
GAINED: 1
A reduction in instruction counts is surprising, but legitimate:
the three shaders helped were spilling, and reducing register
pressure allowed us to issue fewer spills/fills.
total cycles in shared programs:
69035108 ->
68928820 (-0.15%)
cycles in affected programs:
4412402 ->
4306114 (-2.41%)
helped: 4457
HURT: 213
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
foreach_in_list(schedule_node, n, &instructions) {
fs_inst *inst = (fs_inst *)n->inst;
- if (inst->opcode == FS_OPCODE_PLACEHOLDER_HALT ||
- inst->has_side_effects())
+ if ((inst->opcode == FS_OPCODE_PLACEHOLDER_HALT ||
+ inst->has_side_effects()) &&
+ inst->opcode != FS_OPCODE_FB_WRITE)
add_barrier_deps(n);
/* read-after-write deps. */
foreach_in_list(schedule_node, n, &instructions) {
vec4_instruction *inst = (vec4_instruction *)n->inst;
- if (inst->has_side_effects())
+ if (inst->has_side_effects() && inst->opcode != FS_OPCODE_FB_WRITE)
add_barrier_deps(n);
/* read-after-write deps. */