Re: Reusable command buffers

Corentin,

Yeah, we are currently in the same boat w.r.t. ref-counting. Between not 
knowing when things are submitted and the possibility of re-usable 
command buffers in the future, deep ref-counting appeared necessary. But 
if we move to the frame context sort of API that Granite is exposing, 
the perspective is rather interesting. Gotta experiment and benchmark 
that - we don't even have the numbers of wgpu-rs overhead today over raw 
gfx-rs, so the work is cut out for us.

-Dzmitry

On 4/25/19 12:30 PM, 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
>
>