Re: Reusable command buffers

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