Re: Intel driver - DRI profiling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Fri, 2008-03-14 at 08:13 -0600, Kevin DeKorte wrote:
> 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@xxxxxxxxxx>
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@xxxxxxxxxxx
eric@xxxxxxxxxx                         eric.anholt@xxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part

xorg mailing list

[X Forum]     [Devices]     [XFree86]     [XFree86 Newbie]     [Site Home]     [IETF Annouce]     [Security]     [Fontconfig]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Video for Linux]     [Linux RAID]     [Linux Resources]

Powered by Linux