On Sat, Aug 10, 2013 at 5:09 PM, Christian König <deathsim...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
