Re: Reusable command buffers

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>
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
>
>
>