Re: [RFC 2/2] drm/i915: Clean-up PPGTT on context destruction

[Daniel Vetter <daniel@ffwll.ch>]

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@intel.com wrote:
> > > > > From: Rafael Barbalho <rafael.barbalho@intel.com>
> > > > > 
> > > > > 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@ffwll.ch>
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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx