Re: [RFC 00/38] PPGTT dynamic page allocations

From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	Michel Thierry <michel.thierry@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [RFC 00/38] PPGTT dynamic page allocations
Date: Wed, 5 Nov 2014 10:19:47 +0100	[thread overview]
Message-ID: <20141105091947.GV26941@phenom.ffwll.local> (raw)
In-Reply-To: <20141104130109.GP13658@nuc-i3427.alporthouse.com>

On Tue, Nov 04, 2014 at 01:01:09PM +0000, Chris Wilson wrote:
> On Tue, Nov 04, 2014 at 01:44:47PM +0100, Daniel Vetter wrote:
> > On Wed, Oct 08, 2014 at 08:13:33AM +0100, Chris Wilson wrote:
> > > On Tue, Oct 07, 2014 at 06:10:56PM +0100, Michel Thierry wrote:
> > > > This is based on the first 55 patches of Ben's 48b addressing work, taking
> > > > into consideration the latest changes in (mainly aliasing) ppgtt rules.
> > > > 
> > > > Because of these changes in the tree, the first 17 patches of the original
> > > > series are no longer needed, and some patches required more rework than others.
> > > > 
> > > > For GEN8, it has also been extended to work in logical ring submission (lrc)
> > > > mode, as it looks like it will be the preferred mode of operation.
> > > > I also tried to update the lrc code at the same time the ppgtt refactoring
> > > > occurred, leaving only one patch that is exclusively for lrc.
> > > > 
> > > > I'm asking for comments, as this is the foundation for 48b virtual addressing
> > > > in Broadwell. 
> > > 
> > > I find the lack of activity tracking in the current ppgtt design severely
> > > limiting. We have a number of tests (both igt and mesa) that fail
> > > because the ppgtt pins gtt space for its lifetime. Transitioning the
> > > backing pages to a bo allows us to evict, and even shrink, vm along with
> > > regular objects. Plus the dynamic allocation here has also been
> > > discussed with the idea of sparse allocation of bo... Imo, we want to
> > > use bo (probably based on gemfs) for both.
> > 
> > Picking up an old story ... I guess you're talking about the PD
> > reservation ppgtt needs on gen7 and which is stolen from the GGTT?
> > 
> > One totally crazy idea I've had is to add an ->evict function to the vma
> > and just use the vma to track this stuff, with no object attached. That
> > should be enough for the shrinker, presuming we wrap enough code into the
> > optional ->evict callback. By default it'd do the normal bo evict. And
> > with a vfunc ->evict we could also subsume the pageflip stall and ctx
> > switch tricks into the same infrastructure.
> > 
> 
> Strangely enough, it already only uses the vma... It is simplest though
> just to reuse an obj to store the pages and dma addresses (reusing the
> common code), which then ties directly into the evicter over the GGTT,
> and shrinker for normal RAM. The only trick you then need is to create a
> special vma for the pde in ggtt. After my initial concern, with a little
> bit of care using the shmemfs for allocation is only marginally slower
> than alloc_page(). I am not yet convinced about teaching evict/shrink
> new tricks (or specialising the hammers).

Well the new trick would have been used mostly for pageflip and ctx
objects. But maybe not worth the trouble since especially with pageflips
that special type is interim ... We could abuse Tvrtko's ggtt_view stuff
though and hand out special ids for ppgtt pdes and act accordingly.
-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