I think you misread this slide; the current proposal is TBD, but the rough idea of a proposal would let users fork a BG and update it. I thought I put my thoughts on that somewhere (in the Matrix chat, possibly?), but I can't seem to find it. As the slide deck says though, updating on either the queue or device timelines is untenable for validation purposes. That basically leaves content timeline as the best place to do it.

I imagine the API is going to look something like this.

Jasper's Strawman

if (bg.isLocked())
    bg.cloneAndUnlock();
bg.updateBinding(0, myTextureView);

isLocked: returns whether the GPUBindGroup is "locked". A GPUBindGroup becomes locked when attached to a command encoder, an unsubmitted command buffer, or a submitted-but-incomplete command buffer. It automatically unlocks when all command buffers using this bind group have finished submitting.

cloneAndUnlock: forks the GPUBindGroup and forcibly unlocks it. Previous users of this bind group (command encoders that are recording, unsubmitted command buffers, submitted-but-incomplete command buffers) keep their old bindings and do not get these updates. The clone effectively creates a new, separate GPUBindGroup under the hood, making it available for binding updates without waiting on the command buffers to complete first. This method can fail if there is no more descriptor space, however, there's not a lot that API users can do in response here.

Question: should cloneAndUnlock on an unlocked bind group be an error? Is there utility for "forking early", or should we prevent it so that users don't try and use too much heap space.

Question: should clone be interior mutability bg.cloneAndUpdate() or exterior mutability bg = bg.clone(). My preference is the former, but it's not super strongly held; I believe it will just make user code easier to write, as they can just pass around a bg that will keep getting updated; otherwise, they need to pass around a wrapper around a bg.

updateBinding: updates the bind group to put the resource at the given slot. Only works if the GPUBindGroup is unlocked; raises an error otherwise.

Extension: Addition without unlocking

renderPass.setBindGroup(0, bg);
let slot = bg.findFreeSlot();
bg.updateBinding(slot, myBufferView);

findFreeSlot: returns an empty slot in the list of dynamic resource array of a GPUBindGroup and returns it. If none is available, returns null.

updateBinding: updates the bind group to put the resource at the given slot. Only works if the GPUBindGroup is unlocked, or the existing resource at slot is empty; raises an error otherwise.

I believe that adding a resource to an existing GPUBindGroup should be safe to do in a racy manner, but if that's not true, then we don't have to do this.

[bindless] Add the proposal for how bindings are updated in dynamic binding arrays. #5379

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions