Intel driver - DRI profiling

[Eric Anholt]

On Fri, 2008-03-14 at 08:13 -0600, Kevin DeKorte wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Vedran Rodic wrote:
> >>  The driver is, in this case, continously allocating new buffers from the
> >>  kernel to use as batch- and perhaps state buffers. Each new buffer
> >>  allocation means new pages need to be allocated and faulted in using
> >>  nopfn. This is costly.
> > 
> > Seems obvious that it should re-use the old buffers, no?
> 
> Or would it be better to just allocate a bunch of buffers and keep a
> pool of them? Or do allocations of more than one buffer at a time?

commit fe91c05b5494b889c8adda77ff562712116d2e59
Author: Eric Anholt <eric at anholt.net>
Date:   Wed Mar 5 14:14:54 2008 -0800

    [intel] Add a driconf option to cache freed buffer objects for reuse.
    
    This is defaulted off as it has potentially large memory costs for a modest
    performance gain.  Ideally we will improve DRM performance to the point where
    this optimization is not worth the memory cost in any case, or find some
    middle ground in caching only limited numbers of certain buffers.  For now,
    this provides a modest 4% improvement in openarena on GM965 and 10% in openarena
    on GM945.

The idea is that you save buffer objects in an LRU.  When allocating a
new one, check if the LRU buffer has had its last fence signaled, and if
so, use that one instead of allocating.  It's nice that it dynamically
sizes to how much you need to cache to keep the hardware busy, but since
that's a not very limited bounds, I'd rather just cover the buffers we
really need to reuse by default (batch, CURBE, VB temps).  Shouldn't be
hard to do.

At this point the next step for 3d driver performance work seems to be
getting oprofile up and running on my test systems.  As friendly as
sysprof is, its kernel backtraces are just way too broken to guide
further work.

-- 
Eric Anholt                             anholt at FreeBSD.org
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: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080317/3a8afa39/attachment.pgp>