[Intel-gfx] [RFC 00/38] PPGTT dynamic page allocations

[Chris Wilson]

On Wed, Nov 05, 2014 at 10:19:47AM +0100, Daniel Vetter wrote:
> 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.

Hmm, for pageflips it is not that useful unless you give me a method to
pre-bind it elsewhere. Currently, I force a pagefault on objects that
are allocated for use as scanout so that we do not incur the stall when
flipping. Even secondary planes we often use direct access for uploads
and so will also want a ggtt binding before flipping. (If they were
linear, or we used accessors everywhere, we could just ignore the
fence and GGTT for direct access... But that gets complicated and slow
for anything other than simple transfers.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre