On May 25, 2018 15:28:22 Matt Turner <matts...@gmail.com> wrote:
On Thu, May 24, 2018 at 2:56 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote:
From: Francisco Jerez <curroje...@riseup.net>
---
src/intel/compiler/brw_shader.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_shader.cpp
b/src/intel/compiler/brw_shader.cpp
index 141b64e..61211ef 100644
--- a/src/intel/compiler/brw_shader.cpp
+++ b/src/intel/compiler/brw_shader.cpp
@@ -984,7 +984,8 @@
backend_instruction::writes_accumulator_implicitly(const struct gen_device_info
return writes_accumulator ||
(devinfo->gen < 6 &&
((opcode >= BRW_OPCODE_ADD && opcode < BRW_OPCODE_NOP) ||
- (opcode >= FS_OPCODE_DDX_COARSE && opcode <= FS_OPCODE_LINTERP)));
+ (opcode >= FS_OPCODE_DDX_COARSE && opcode <=
FS_OPCODE_LINTERP))) ||
+ (devinfo->gen < 7 && opcode == FS_OPCODE_LINTERP);
That's heavy-handed. Won't this prevent the scheduler from reordering
LINTERP instructions, even though we can only run into problems on
SIMD32?
As long as none of them declare that they read it, re-ordering should be
fine. If we don't do this, the compiler may move a LINTERP between a write
and read of the accumulator emitted for some other reason. That said,
this reminds me that we should probably back-port a patch that declares
that they write the accumulator on gen11+ too.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
