[Intel-gfx] [PATCH] drm/agp: agp-intel/i915: trim stolen space to 16M

[Jesse Barnes]

On Wed, 24 Mar 2010 13:06:05 -0700
Eric Anholt <eric at anholt.net> wrote:

> On Mon, 22 Mar 2010 11:17:46 -0700, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> > On my SDV, the BIOS allocates 128M of stolen space no matter what
> > settings I use.  This leaves very little aperture space available (at
> > least relatively so given my 30" + 24" desktop setup) for mapping
> > buffers in execbuf.
> > 
> > I've been using this patch for awhile to work around the problem, and
> > think it's a reasonable thing to apply.  We generally only need a small
> > amount of stolen space for the few things that need contiguous space,
> > the compressed frame buffer being the biggest.
> > 
> > I think I have an idea of how to reclaim the space and give it back to
> > linux, but I haven't tested that yet; I'll post a follow-up patch on
> > top of this one when I have it working (basically changing the memory
> > back to WB using MTRR and/or set_memory_* calls and using memory
> > hotplug's add_memory() call to return it to the system).
> > 
> > Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
> 
> I love the idea!  The interactions between the two modules are sure
> ugly, though -- like the duplication of i915_probe_agp().  That's part
> of why I've wished we would just pull GTT setup into the DRM and leave
> intel-agp to rot for non-KMS support that actually uses the agpgart
> interfaces.

Agreed.  I briefly looked at cleaning that up too, but it seemed pretty
invasive to the AGP and DRM code, so I left it for another day.

> Given that the DRM wants a variable amount of the stolen memory for its
> purposes, it seems like we need for the DRM to be able to tell AGP how
> much it should give back.  Probably easiest would be for DRM to just do
> that by binding things in at lower addresses if it feels like, and AGP
> should just do whatever the DRM says without checking if the DRM's
> offset happened to be in stolen.

Yeah that would probably be better, and would be easier after reworking
things.

-- 
Jesse Barnes, Intel Open Source Technology Center