The reason why it was safe for the scheduler to ignore the side
effects of framebuffer write instructions was that its side effects
couldn't have had any influence on any other instruction in the
program, because we weren't doing framebuffer reads, and framebuffer
writes were always non-overlapping. We need actual memory dependency
analysis in order to determine whether a side-effectful instruction
can be reordered with respect to other instructions in the program.
---
src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
index 8afdc25..81166a5 100644
--- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
+++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
@@ -901,8 +901,7 @@ is_scheduling_barrier(const fs_inst *inst)
{
return inst->opcode == FS_OPCODE_PLACEHOLDER_HALT ||
inst->is_control_flow() ||
- inst->eot ||
- (inst->has_side_effects() && inst->opcode != FS_OPCODE_FB_WRITE);
+ inst->has_side_effects();
}
void
--
2.9.0
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
