| Message ID | 20181122120837.23474-3-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/3] drm/i915/selftests: Flush the test object on creation | expand |
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 */ } }
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@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> --- drivers/gpu/drm/i915/intel_engine_cs.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)