- From: Dzmitry Malyshau <dmalyshau@mozilla.com>
- Date: Thu, 25 Apr 2019 14:51:39 -0400
- To: DevSH Graphics Programming on Gmail <devsh.graphicsprogramming@gmail.com>, Corentin Wallez <cwallez@google.com>
- Cc: public-gpu@w3.org, maister@archlinux.us
Yes, essentially the "Frame Context" can be seen as a command pool with a set of references to all resources (buffers, textures, etc) used by it. Now that I think of it, we have more reasons to track resources (on a command buffer level) than just for ref-counting: we also store information about what states a resource is at the beginning and end of the execution. That is something not being solved by the "Frame Context" idea, at least in the first approximation. -Dzmitry On 4/25/19 1:23 PM, DevSH Graphics Programming on Gmail wrote: > 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 18:52:10 UTC