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