On Tue, Jun 30, 2015 at 01:47:06PM +0100, Chris Wilson wrote: > On Tue, Jun 30, 2015 at 02:07:41PM +0200, Daniel Vetter wrote: > > 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. > > In that scheme, our backing storage is incoherent with the actual > contents. So we don't need the backing storage at all after setting the > PTE and the entire object is volatile (so not saved across hibernate > anyway). We wouldn't want to reserve stolen space for that, just a > custom allocator and discard the pages asap. (Or we have a phys object > scheme that does a lot of copying...) 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. 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. -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
