On Wed, Feb 06, 2013 at 09:31:21AM +0000, Chris Wilson wrote:
> The unbound tracking of objects is an optimisation to avoid costly
> domain transfers whilst the system is rendering. Across suspend, the
> objects will be involuntarily moved out of the GTT domain and will
> require fixup upon resume. Rather than perform those clflushes for all
> objects immediately upon resume, just move them out of the unbound
> tracking list on suspend and lazily reload them from the CPU domain as
> and when they are used afterwards.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Similar comment about fast resume performance: I think we should only do
these when freezing for hibernation. Otherwise browser performance with
cool new stuff like the fast S1x suspend (or whatever it's called again)
will be a horrible experience. Every time you just read for a few
seconds and the system suspend in the background we'll drop all gem bo's
on the floor ...
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index f6ef53f..db14c73 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3912,6 +3912,17 @@ void i915_gem_free_object(struct drm_gem_object
> *gem_obj)
> i915_gem_object_free(obj);
> }
>
> +static void
> +i915_gem_discard_unbound(struct drm_i915_private *dev_priv)
> +{
> + struct drm_i915_gem_object *obj, *next;
> +
> + list_for_each_entry_safe(obj, next,
> + &dev_priv->mm.unbound_list,
> + gtt_list)
> + (void)i915_gem_object_put_pages(obj);
> +}
> +
> int
> i915_gem_idle(struct drm_device *dev)
> {
> @@ -3936,6 +3947,19 @@ i915_gem_idle(struct drm_device *dev)
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> i915_gem_evict_everything(dev);
>
> + /* For KMS we just want to discard the unbound list as it will
> + * change domains when thawing - and restoring its domain upon
> + * resume seems like a false optimisation. Also note that discarding
> + * the unbound list will have the useful side-effect of dropping
> + * purgeable objects which it seems pointless to restore as they are
> + * merely a userspace cache.
> + * However, we may still have some pinned objects (like dma-buf)
> + * that cannot simply be discarded and will require domain
> + * restoration upon resume.
> + */
> + if (drm_core_check_feature(dev, DRIVER_MODESET))
> + i915_gem_discard_unbound(dev_priv);
> +
> i915_gem_reset_fences(dev);
>
> /* Hack! Don't let anybody do execbuf while we don't control the chip.
> --
> 1.7.10.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
