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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx