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

Eric Anholt eric at anholt.net
Wed Mar 24 21:06:05 CET 2010

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

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100324/f946463b/attachment.sig>

More information about the Intel-gfx mailing list