On Tue, Jun 30, 2015 at 12:54:02PM +0200, Daniel Vetter wrote: > > + if (obj->ops->release) > > + obj->ops->release(obj); > > + > > + obj->base.filp = file; > > + obj->ops = &i915_gem_object_ops; > > + > > + obj->base.read_domains = I915_GEM_DOMAIN_CPU; > > + obj->base.write_domain = I915_GEM_DOMAIN_CPU; > > maybe wrap up in a shmem_reinit function and reuse in the gem object creation > path for a bit more clarity (and to reduce chances we forget about this). A bit dubious about this. I like the explicit domain handling as it clearly matches the status of obj->file. The only thing that is then shared with the normal creation is obj->ops, which is actually set in i915_gem_object_init(). It's not clear that we actually have semantic reuse with gem object creation. > Wrt igt not sure whether we can do this in general, since it requires a > working swap partition and working initrd support for hibernate. And > hibernate is kinda a disregarded feature anyway, so imo meh. We could do > an igt_system_hibernate_autowake() if we do the test though. I was thinking of just a flush-stolen-to-shmemfs debugfs interface. With create2 we will be able to create the stolen objects and can use the existing debugfs files to verify placement. > Imo trying to migrate backwards would be serious pain since we'd need to > make sure no shm mmap is around and audit all the other places. Too much > trouble for no gain (userspace can just realloc if needed). Otoh, that would be a userspace error since part of the stolen ABI is that CPU mmaps are verboten. The simplest way to do this would be keep the obj->base.filp private (so not to change the ABI of initially stolen objects) and then fix the existing i915_gem_object_get_pages_stolen() function (which is currently a BUG()) to do the stolen recreation. However, that introduces the possibilty of an error being returned to userspace, so at that point to hide the failure we probably do want to a full shmemfs conversion. Hmm, honestly that seems quite tractable and self-contained. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
