On 25 August 2016 at 10:15, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> Recently I have been applying an optimisation to avoid stalling and
> clflushing GGTT objects based on their current binding. That is we only
> set-to-gtt-domain upon first bind. However, on hibernation the objects
> remain bound, but they are in the CPU domain. Currently (since commit
> 975f7ff42edf ("drm/i915: Lazily migrate the objects after hibernation"))
> we only flush scanout objects as all other objects are expected to be
> flushed prior to use. That breaks down in the face of the runtime
> optimisation above - and we need to flush all GGTT pinned objects
> (essentially ringbuffers).
>
> To reduce the burden of extra clflushes, we only flush those objects we
> cannot discard from the GGTT. Everything pinned to the scanout, or
> current contexts or ringbuffers will be flushed and rebound. Other
> objects, such as inactive contexts, will be left unbound and in the CPU
> domain until first use after resuming.
>
> Fixes: 7abc98fadfdd ("drm/i915: Only change the context object's domain...")
> Fixes: 57e885318119 ("drm/i915: Use VMA for ringbuffer tracking")
> References: https://bugs.freedesktop.org/show_bug.cgi?id=94722
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxx>
> Cc: David Weinehall <david.weinehall@xxxxxxxxx>
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 570e7311a419..72d03127dec4 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3234,7 +3234,7 @@ void i915_gem_restore_gtt_mappings(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct i915_ggtt *ggtt = &dev_priv->ggtt;
> - struct drm_i915_gem_object *obj;
> + struct drm_i915_gem_object *obj, *on;
> struct i915_vma *vma;
An opportune time to make the vma local.
Reviewed-by: Matthew Auld <matthew.auld@xxxxxxxxx>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
