It turns 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@xxxxxxxxxxxxxxxxxx> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> --- 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
