Re: Reusable command buffers

The memory fragmentation, isn't that why Vulkan Command Pools were created?
And Resetting/clearing/reclaiming a pool at once?

Maybe for reusable command buffers WebGPU implementation would need a
concept of a pool as well?
Maybe tie the lifetime of a pool to something and refcount the pool?

On 25/04/2019 17:30, Corentin Wallez wrote:
> Agreed, the articles are extremely interesting and well-written. What's
> really funny is that the design of Dawn (current and planned) is pretty
> close to what Hans is doing in Granite.
> 
> We're doing deep reference counting of resources in command buffers in
> Dawn and I'd be pretty interested in benchmarking it to see what the
> cost of the reference counting ends up being. This is necessary at the
> moment because we have no guarantee of when the command buffer will be
> submitted. If refcounting get too expensive we could imagine a command
> buffer creation option that forces it to be submitted as part of the
> next queue submit, which could remove the need for deep reference counting.
> 
> On Wed, Apr 24, 2019 at 11:15 PM Ken Russell <kbr@google.com
> <mailto:kbr@google.com>> wrote:
> 
>     Thanks for sharing this article Dzmitry. The points about reusable
>     command buffers increasing memory fragmentation, not really being
>     fully reusable, and increasing the complexity of tracking and of the
>     implementation, are good ones and good food for thought.
> 
>     -Ken
> 
> 
>     On Wed, Apr 24, 2019 at 7:18 AM Dzmitry Malyshau
>     <dmalyshau@mozilla.com <mailto:dmalyshau@mozilla.com>> wrote:
> 
>         Hi WebGPU,
> 
>         I was just reading about Granite [1] and found something
>         interesting:
> 
>         http://themaister.net/blog/2019/04/17/a-tour-of-granites-vulkan-backend-part-2/
> 
> 
>         Basically, the goals of Granite are similar to ours - to provide a
>         usable API abstraction over low-level, which for Granite's case
>         is just
>         Vulkan. It also aims to automatically track resource lifetimes,
>         safely
>         retiring them after GPU no longer needs them.
> 
> 
>         The interesting point I stumbled upon is the fact Granite
>         doesn't expose
>         re-usable command buffers and argues against their usefulness.
>         Perhaps,
>         if anybody is at Khronos F2F right now, we can reach out to Hans
>         personally and get more details.
> 
>         Another interesting aspect is the rule it establishes that a
>         command
>         buffer created in a frame context has to be submitted in the
>         same frame
>         context. This is another way to communicate submission order by
>         the user
>         (a distant alternative to "enqueue" semantics), and it has the
>         benefit
>         of greatly simplifying the tracking logic in the implementation, as
>         described in the blog. For us it would mean a tiny complication
>         in the
>         API in exchange of potentially less overhead in tracking (yet to be
>         confirmed).
> 
>         Just posting it here to get thoughts rolling in our heads before
>         the May
>         F2F, where we can hopefully discuss this.
> 
> 
>         Thanks,
> 
>         Dzmitry
> 
>

Received on Thursday, 25 April 2019 17:24:14 UTC