[Intel-gfx] [PATCH] drm/i915: Use drm_mm for PPGTT PDEs

[Chris Wilson]

On Thu, Apr 11, 2013 at 08:36:26AM -0700, Ben Widawsky wrote:
> On Thu, Apr 11, 2013 at 07:10:50AM +0100, Chris Wilson wrote:
> > On Wed, Apr 10, 2013 at 07:43:39PM -0700, Ben Widawsky wrote:
> > > I think this is a nice generalization on it's own, but it's primarily
> > > prep work for my PPGTT support. Does this bother anyone?
> > > 
> > > The only down side I can see is we waste 2k of cpu unmappable space
> > > (unless we have something else that is <= 2k and doesn't need to be page
> > > aligned).
> > > 
> > > It's RFC because I have only hacked this up and haven't thoroughly
> > > tested a bunch of error and suspend/resume paths.
> > 
> > Ugh. Fragmentation, you need a top down allocator.
> > -Chris
> 
> For the current case we can easily address this by setting the range to
> be the old range and keep the existing allocator but limit it to the
> same portion it used before. This isn't very interesting though and the
> previous code is probably better suited for this case anyway since it's
> inherently much more robust against accidentally overwriting the PDEs.

As discussed, my concern here is that we are limiting the maximum
object size by placing very long lived and unmovable objects right in
the middle of the GTT.
 
> Would you agree that on GEN7 + multiple PPGTTs; the fragmentation is a
> "don't care"?

Yes. Given true ppggt, then we mostly only care about fragmentation in
the mappable region.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre