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

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Jun 30, 2015 at 12:25:54PM +0100, Chris Wilson wrote:
> On Tue, Jun 30, 2015 at 12:54:02PM +0200, Daniel Vetter wrote:
> > The gpu should be able so pinned for scanout is the only corner case I can
> > think of atm.
> 
> Hmm. That's a nuisance. But... We can throw away all the VM bindings
> that are unpinned, and then rewrite those that are left with the shmemfs
> pages.
> 
> It's ugly. On migration back we would have to do a similar trick, and we
> need to tell a few white lies to get past some of our internal BUG_ON.
> However, as the contents are the same and the PTE writes are atomic into
> the GGTT, it should be invisible to the user.
> 
> For internally allocated frontbuffers, I was expecting to mark them as
> volatile and let them lose their contents across hibernation - because
> they will be immediately cleared afterwards (at least so I expect).

New upcoming complications: On some still super-secret upcoming platform
we need special ggtt vmas for scanout, to pin the backing storage into
suitable memory. And because the hw implementation does replace the ggtt
pte with the physical page entry (i.e. resolving dmar and stuff) it
disallows any writes to the ptes. So we can't replace the ggtt ptes while
the vma is pinned at all.

So I guess the scheme would need to be:
- On hibernate migrate the backing storage around shmem.
- On resume we need to repin (need to do that anyway) with the new vma
  settings.

Cheers, 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