[Mesa-dev] [PATCH 16/20] radeonsi: add FMASK texture binding slots and resource setup

Daniel Vetter daniel at ffwll.ch
Sun Aug 11 02:53:09 PDT 2013


On Sat, Aug 10, 2013 at 05:36:07PM +0200, Marek Olšák wrote:
> On Sat, Aug 10, 2013 at 5:09 PM, Christian König
> <deathsimple at vodafone.de> wrote:
> > Am 10.08.2013 15:53, schrieb Marek Olšák:
> >
> >> The RCU approach sounds good, but you can never know if 16 is enough.
> >> We should release the buffer once it is full and allocate a new one.
> >> The cache bufmgr in the winsys will assure there won't be any buffer
> >> allocation overhead - it would work kinda a like a ring of buffers.
> >
> >
> > Are you sure of that? The overhead of allocating a new buffer was what
> > always looked so unfriendly to me with this approach.
> 
> Absolutely. We've had this optimization since 2010 or so. As long as
> you use winsys->buffer_create(use_reusable_pool=TRUE), you're fine. A
> deleted buffer is added to a list of deleted buffers and if nobody
> reclaims it, it will be released after 1 second. During that 1 second,
> the buffer must first become idle and then anybody can reclaim it with
> the same buffer_create call. If the buffer had been mapped before,
> it's still mapped, so there is even no map-buffer overhead. This is a
> crucial part of our driver stack that makes vertex uploading so
> efficient. Don't underestimate the Radeon winsys. :)

Just an fyi how we do that for libdrm_intel: We have an madv ioctl, and
every buffer in the allocation cache is marked purgeable. When memory gets
tight the kernel can drop the backing storage on the floor right away for
such buffers (and we preferrentially reap such objects from our shrinker).
When reusing such a buffer libdrm calls madv(WILLNEED) to make sure the
buffer is still around. If it got reaped libdrm cleans up the entire cache
and checks for other reaped buffer objects.

With this you don't need tunables like the 1s delay you're using and
instead cache size is directly driven by vm pressure.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the mesa-dev mailing list