drm/i915: Skip clearing the GGTT on full-ppgtt systems
Under full-ppgtt, access to the global GTT is carefully regulated through hardware functions (i.e. userspace cannot read and write to arbitrary locations in the GGTT via the GPU). With this restriction in place, we can forgo clearing stale entries from the GGTT as they will not be accessed. For aliasing-ppgtt, we could almost do the same except that we do allow userspace access to the global-GTT via execbuf in order to workraound some quirks of certain instructions. (This execbuf path is filtered out with EINVAL on full-ppgtt.) The most dramatic effect this will have will be during resume, as with full-ppgtt the GGTT is only used sparingly. References: https://bugs.freedesktop.org/show_bug.cgi?id=94722 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Weinehall <david.weinehall@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Tested-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463207195-22076-4-git-send-email-chris@chris-wilson.co.uk
This commit is contained in:
parent
975f7ff42e
commit
f7770bfd9f
|
@ -2477,6 +2477,13 @@ static void gen6_ggtt_insert_entries(struct i915_address_space *vm,
|
||||||
assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
|
assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
static void nop_clear_range(struct i915_address_space *vm,
|
||||||
|
uint64_t start,
|
||||||
|
uint64_t length,
|
||||||
|
bool use_scratch)
|
||||||
|
{
|
||||||
|
}
|
||||||
|
|
||||||
static void gen8_ggtt_clear_range(struct i915_address_space *vm,
|
static void gen8_ggtt_clear_range(struct i915_address_space *vm,
|
||||||
uint64_t start,
|
uint64_t start,
|
||||||
uint64_t length,
|
uint64_t length,
|
||||||
|
@ -3072,14 +3079,17 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
|
||||||
|
|
||||||
ret = ggtt_probe_common(dev, ggtt->size);
|
ret = ggtt_probe_common(dev, ggtt->size);
|
||||||
|
|
||||||
ggtt->base.clear_range = gen8_ggtt_clear_range;
|
|
||||||
if (IS_CHERRYVIEW(dev_priv))
|
|
||||||
ggtt->base.insert_entries = gen8_ggtt_insert_entries__BKL;
|
|
||||||
else
|
|
||||||
ggtt->base.insert_entries = gen8_ggtt_insert_entries;
|
|
||||||
ggtt->base.bind_vma = ggtt_bind_vma;
|
ggtt->base.bind_vma = ggtt_bind_vma;
|
||||||
ggtt->base.unbind_vma = ggtt_unbind_vma;
|
ggtt->base.unbind_vma = ggtt_unbind_vma;
|
||||||
|
|
||||||
|
ggtt->base.clear_range = nop_clear_range;
|
||||||
|
if (!USES_FULL_PPGTT(dev_priv))
|
||||||
|
ggtt->base.clear_range = gen8_ggtt_clear_range;
|
||||||
|
|
||||||
|
ggtt->base.insert_entries = gen8_ggtt_insert_entries;
|
||||||
|
if (IS_CHERRYVIEW(dev_priv))
|
||||||
|
ggtt->base.insert_entries = gen8_ggtt_insert_entries__BKL;
|
||||||
|
|
||||||
return ret;
|
return ret;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue