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

[Daniel Vetter]

On Mon, Feb 23, 2015 at 04:52:46PM +0000, Barbalho, Rafael wrote:
> 
> 
> > -----Original Message-----
> > From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> > Sent: Monday, February 23, 2015 4:50 PM
> > To: Daniel Vetter
> > Cc: Barbalho, Rafael; intel-gfx at lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [RFC 2/2] drm/i915: Clean-up PPGTT on context
> > destruction
> > 
> > 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:
> > > > > 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.
> > 
> > As I have said and shown, that is very easy to rectify and has, for
> > example, nice side-effects of basically making operating on fences free
> > of blocking on the GPU if the object is busy only in the ppgtt. The
> > principle use is so that we are consistent in vma vs obj tracking and
> > make the code much cleaner imo.
> 
> My initial implementation was tracking the vma in the request structure but it
> wasn't as clean. I'll take everything that has been said on-board and clean
> things up, and add an igt test too while I am at it.

Conceptually I guess we could split up the active list into something
per-request, at least right now. But I think that will totally upset the
scheduler work, so just moving obj->active to vmas should be a lot less
intrusive indeed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch