[Intel-gfx] [PATCH] Use buffer objects for binding table and surface-state objects.

[Eric Anholt]

On Tue, 2008-11-04 at 18:14 +0100, Lukas Hejtmanek wrote:
> On Tue, Nov 04, 2008 at 08:33:40AM -0800, Carl Worth wrote:
> > For example, in the current driver there's still a one-time allocation
> > of memory up front into two regions---one for 3D and one for 2D. The
> > percentage given to each is configurable in your xorg.conf file, but you
> > only get one number to control the upfront allocation. So what happens
> > is if one of these is too small and gets full then performance starts
> > suffering very badly. But with GEM we'll be able to dynamically adapt to
> > circumstances as needed. So that will be a big win.
> 
> So, this would explain why a long running X server gets slower and slower,
> right?

The performance characteristics of the EXA memory manager are, well,
bad.  It's things like "squared with number of allocations that are
already in offscreen".

> The 2D buffer is probably highly fragmented and new objects do not fit
> in.

We're good at kicking things out in EXA.  It hurts, since it's not using
GEM and eviction is thus incredibly expensive, leading to all the "read
as few pixels as possible" migration hacks that people did in EXA.  But
there shouldn't be anything that's sticking somewhere and keeping things
from getting moved in.

> Is there something that could be done here? Given we have GEM in the
> kernel, we could provide something like /proc/buddyinfo also for the GEM
> memory manager?

Someone could add that debugging, and it might be interesting to look at
(though I'm really interested in seeing what the whole aperture layout
looks like, often).  Other useful debug info would be to attach names to
objects in the kernel so our debugging could give us stats on types of
objects (oh, hey, you're leaking surface state objects).

> Is there any defragmentation algorithm?

Nope.  One of the reasons not to is that that means blitting everybody
around, which is a performance cost that's surely on par with evicting
everything in the GTT, now that eviction and rebinding cost is so low
(it could go lower, too, at the expense of leaving more buffers pinned
in memory.  the plan is to use a VM pressure handler to respond
appropriately and unpin).

-- 
Eric Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20081104/76ddd3e5/attachment.sig>