@@ -1366,13 +1366,15 @@ static int load_pd_dir(struct i915_request *rq, const struct i915_ppgtt *ppgtt)
const struct intel_engine_cs * const engine = rq->engine;
u32 *cs;
- cs = intel_ring_begin(rq, 6);
+ cs = intel_ring_begin(rq, 8);
if (IS_ERR(cs))
return PTR_ERR(cs);
- *cs++ = MI_LOAD_REGISTER_IMM(1);
+ *cs++ = MI_LOAD_REGISTER_IMM(2);
*cs++ = i915_mmio_reg_offset(RING_PP_DIR_DCLV(engine->mmio_base));
*cs++ = PP_DIR_DCLV_2G;
+ *cs++ = i915_mmio_reg_offset(RING_PP_DIR_DCLV(engine->mmio_base)) + 4;
+ *cs++ = 0;
*cs++ = MI_LOAD_REGISTER_IMM(1);
*cs++ = i915_mmio_reg_offset(RING_PP_DIR_BASE(engine->mmio_base));
@@ -1579,6 +1581,7 @@ static int switch_context(struct i915_request *rq)
{
struct intel_context *ce = rq->hw_context;
struct i915_address_space *vm = vm_alias(ce);
+ u32 hw_flags = 0;
int ret;
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
@@ -1587,22 +1590,16 @@ static int switch_context(struct i915_request *rq)
ret = load_pd_dir(rq, i915_vm_to_ppgtt(vm));
if (ret)
return ret;
+
+ ret = load_pd_dir(rq, i915_vm_to_ppgtt(vm));
+ if (ret)
+ return ret;
}
if (ce->state) {
- u32 hw_flags;
-
GEM_BUG_ON(rq->engine->id != RCS0);
- /*
- * The kernel context(s) is treated as pure scratch and is not
- * expected to retain any state (as we sacrifice it during
- * suspend and on resume it may be corrupted). This is ok,
- * as nothing actually executes using the kernel context; it
- * is purely used for flushing user contexts.
- */
- hw_flags = 0;
- if (i915_gem_context_is_kernel(rq->gem_context))
+ if (!rq->engine->default_state)
hw_flags = MI_RESTORE_INHIBIT;
ret = mi_set_context(rq, hw_flags);
@@ -1987,8 +1987,15 @@ static struct i915_ppgtt *gen6_ppgtt_create(struct drm_i915_private *i915)
goto err_scratch;
}
+ /* Preallocate all entries, dynamic updates do not fly very well! */
+ err = gen6_alloc_va_range(&ppgtt->base.vm, 0, ppgtt->base.vm.total);
+ if (err)
+ goto err_vma;
+
return &ppgtt->base;
+err_vma:
+ i915_vma_put(ppgtt->vma);
err_scratch:
free_scratch(&ppgtt->base.vm);
err_pd:
@@ -436,7 +436,7 @@ static const struct intel_device_info intel_sandybridge_m_gt2_info = {
.has_rc6 = 1, \
.has_rc6p = 1, \
.has_rps = true, \
- .ppgtt_type = INTEL_PPGTT_ALIASING, \
+ .ppgtt_type = INTEL_PPGTT_FULL, \
.ppgtt_size = 31, \
IVB_PIPE_OFFSETS, \
IVB_CURSOR_OFFSETS, \
@@ -493,7 +493,7 @@ static const struct intel_device_info intel_valleyview_info = {
.has_rps = true,
.display.has_gmch = 1,
.display.has_hotplug = 1,
- .ppgtt_type = INTEL_PPGTT_ALIASING,
+ .ppgtt_type = INTEL_PPGTT_FULL,
.ppgtt_size = 31,
.has_snoop = true,
.has_coherent_ggtt = false,
After much hair pulling, resort to preallocating the ppGTT entries on init to circumvent the apparent lack of PD invalidate following the write to PP_DCLV upon switching mm between contexts (and here the same context after binding new objects). However, the details of that PP_DCLV invalidate are still unknown, and it appears we need to reload the mm twice to cover over a timing issue. Worrying. Fixes: 3dc007fe9b2b ("drm/i915/gtt: Downgrade gen7 (ivb, byt, hsw) back to aliasing-ppgtt") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- .../gpu/drm/i915/gt/intel_ring_submission.c | 23 ++++++++----------- drivers/gpu/drm/i915/i915_gem_gtt.c | 7 ++++++ drivers/gpu/drm/i915/i915_pci.c | 4 ++-- 3 files changed, 19 insertions(+), 15 deletions(-)