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

Daniel Vetter daniel at ffwll.ch
Tue Nov 4 13:44:47 CET 2014


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.

Just food for thoughts.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



More information about the Intel-gfx mailing list