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

[Marek Olšák]

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. :)


>
> On the other hand the CP definitely can't handle more than 8 contexts at the
> same time (and one of them is always the clear context), so I strongly think
> we should be on the save side with 16 slots here. I'm just not sure if the
> SQ could add some more depth to our pipeline, maybe Alex knows more on this.

If we needed only 16 slots, that would be even better.

Marek