You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
metal: Create a global residency set, holding all allocated heaps (#273)
`gpu-allocator` creates heaps on which callers can allocate ranges
and create "placed" resources like textures, buffers and acceleration
structures. These individual resources, or the heaps as a whole,
need to be made resident on the command buffer or even globally on an
entire queue.
In the previous API those heaps had to be made resident on individual
command *encoders* with `useHeap(s):` (making an entire heap resident
perfectly matches a bindless design, as opposed to making every
individual resource -either placed on the heap or allocated separately-
resident with `useResource(s):`). Worse, this API only applies
`MTLResourceUsageRead` (exluding `RenderTarget` and `ShaderWrite`
textures) which would disallow any resources on the heap to be written.
Now with `MTLResidencySet` multiple heaps can be made resident with one
call, defeating the performance overhead of individually "using" all
heaps on *every* command *encoder*. But without tracking this inside
`gpu-allocator`, users of our crate still have to manually rebuild
this `MTLResidencySet` each time they change their allocations, without
knowing when `gpu-allocator` created or destroyed a heap.
By managing a single updated `MTLResidencySet` in `gpu-allocator`,
callers can simply call `.commit()` on this object right before they
submit command buffers referencing resources on these heaps, as long as
they have the residency set attached to the queue in question or "used"
on the command buffer that is being submitted. This removes all the
performance overhead of repeatedly creating `MTLResidencySet`s, which
otherwise defeats the purpose of it over plain `useHeap(s):` call(s).
0 commit comments