Re: [PATCH] drm/i915: Migrate stolen objects before hibernation

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, Jul 01, 2015 at 01:59:23PM +0100, Chris Wilson wrote:
> On Wed, Jul 01, 2015 at 02:47:15PM +0200, Daniel Vetter wrote:
> > The backing storage will still be coherent, it's just that the specific
> > view used to scan it out can't be touched at all (i.e. not even ptes
> > rewritten) while in use. Which means you can't rewrite pts, that's all.
> 
> Hmm, I thought there was going to be some fenced off memory. I was
> hoping to avoid allocating any ourseleves :)

It works like a cache, but with some funky pinning which needs a separate
view because that's how the hw works.

> > We can still copy the actual backing storage using a new ggtt view
> > (they'll have different types) and convert to shmem. It's only that
> > rewriting the ptes for the scanout view can only happen on resume from
> > hibernate (we need to restore it all ofc again). Youre description above
> > sounded like you wanted to rewrite all ptes right away which I think isn't
> > need and at least with that fancy platform not possible - if we have
> > concurrent writes while we do the conversion there's a bug anyway.
> 
> It's just the difference between making the function a generic
> migrate-stolen-to-shmem, and making it peculiar to hibernate.
> 
> But yes, since we need to rebind all the vma after hibernate, we can add
> a parameter to tell us to skip it during migrate() and expect everything
> to come out in the wash (since the stolen memory won't be reused).

Yeah generic stolen-to-shmem is probably overshooting for this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx