Revert "i965: Don't add barrier deps for FB write messages."

This reverts commit d0e1d6b7e2.

The change in the vec4 code is a mistake -- there's never an
FS_OPCODE_FB_WRITE in vec4 code.

The change in the fs code had the (harmless) effect of not recognizing
an FB_WRITE as a scheduling barrier even if it was marked EOT --
harmless because the scheduler marked the last instruction of a block as
a barrier, something I'm changing in the following patches.

This will be reimplemented later in the series.
This commit is contained in:
Matt Turner 2016-02-17 11:04:50 -08:00
parent 0d253ce34a
commit 436bdd7403

View file

@ -939,9 +939,8 @@ fs_instruction_scheduler::calculate_deps()
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()) &&
inst->opcode != FS_OPCODE_FB_WRITE)
if (inst->opcode == FS_OPCODE_PLACEHOLDER_HALT ||
inst->has_side_effects())
add_barrier_deps(n);
/* read-after-write deps. */
@ -1183,7 +1182,7 @@ vec4_instruction_scheduler::calculate_deps()
foreach_in_list(schedule_node, n, &instructions) {
vec4_instruction *inst = (vec4_instruction *)n->inst;
if (inst->has_side_effects() && inst->opcode != FS_OPCODE_FB_WRITE)
if (inst->has_side_effects())
add_barrier_deps(n);
/* read-after-write deps. */