[Intel-gfx] [PATCH 3/3] drm/i915: Avoid using MI_STORE_DWORD_IMM on vecs
Chris Wilson
chris at chris-wilson.co.uk
Thu Nov 22 12:08:37 UTC 2018
It runs out that our MI_FLUSH_DW we perform after each batch is not
sufficient to flush MI_STORE_DWORD_IMM to memory. Of course, this raises
the concern that MI_FLUSH_DW may not be flushing anything on vecs, but
for the moment we have to neuter our own use of store-dw.
I have tried:
8x MI_FLUSH_DW (with post-op sync)
8x MI_STORE_DWORD_IMM
8x MI_STORE_REG_MEM + MI_LOAD_REG_MEM
with no lasting effect; they only appear to add some extra delay on the
flush which partially masks the issue but not solve it.
Testcase: igt/i915_selftest/live_coherency
Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
---
drivers/gpu/drm/i915/intel_engine_cs.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c
index 759c0fd58f8c..117667cfbda1 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1195,10 +1195,14 @@ bool intel_engine_can_store_dword(struct intel_engine_cs *engine)
case 3:
/* maybe only uses physical not virtual addresses */
return !(IS_I915G(engine->i915) || IS_I915GM(engine->i915));
+ case 4:
+ case 5:
+ /* no known limitations */
+ return true;
case 6:
return engine->class != VIDEO_DECODE_CLASS; /* b0rked */
default:
- return true;
+ return engine->class != VIDEO_ENHANCEMENT_CLASS;/* incoherent */
}
}
--
2.19.1
More information about the Intel-gfx
mailing list