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 :) > 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). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
