On Mon, Feb 23, 2015 at 05:41:51PM +0100, Daniel Vetter wrote: > On Fri, Feb 13, 2015 at 10:34:51AM +0000, Chris Wilson wrote: > > On Fri, Feb 13, 2015 at 10:55:46AM +0100, Daniel Vetter wrote: > > > On Thu, Feb 12, 2015 at 09:03:06PM +0000, Chris Wilson wrote: > > > > On Thu, Feb 12, 2015 at 08:05:02PM +0000, rafael.barbalho@xxxxxxxxx wrote: > > > > > From: Rafael Barbalho <rafael.barbalho@xxxxxxxxx> > > > > > > > > > > With full PPGTT enabled an object's VMA entry into a PPGTT VM needs to be > > > > > cleaned up so that the PPGTT PDE & PTE allocations can be freed. > > > > > > > > > > This problem only shows up with full PPGTT because an object's VMA is > > > > > only cleaned-up when the object is destroyed. However, if the object has > > > > > been shared between multiple processes this may not happen, which leads to > > > > > references to the PPGTT still being kept the object was shared. > > > > > > > > > > Under android the sharing of GEM objects is a fairly common operation, thus > > > > > the clean-up has to be more agressive. > > > > > > > > Not quite. You need an active refcount as we do not expect close(fd) to > > > > stall. The trick is to "simply" use requests to retire vma (as well as > > > > the object management it does today, though that just becomes a second > > > > layer for GEM API management, everything else goes through vma). > > > > > > Linking into the ctx unref should give us that for free since requests do > > > hold a reference on the context. So this will only be run when the buffers > > > are idle. > > > > > > Well except that our unbind code is too dense to do that correctly for > > > shared buffers, so we need to move obj->active to vma->active first. > > > > We unbind vma, so what do you mean? > > The unbind of the vma will block since we track active per-obj instead of > per-vma. Which is kinda not that cool for a kref_put cleanup function. > > But yeah the below is what I had in mind too, with the mentioned nuisance > fixed. Oh and there's a fun bit of code to clean up - in the execbuf code we just pin the 2nd vma for the ggtt, which crucially relies on the ->active boolean being shared by all vmas. That needs to be fixed first before we can move obj->active to vma->active. For context see commit da51a1e7e398129d9fddd4b26b8469145dd4fd08 Author: Daniel Vetter <daniel.vetter@xxxxxxxx> Date: Mon Aug 11 12:08:58 2014 +0200 drm/i915: Fix secure dispatch with full ppgtt Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx