WebGPU: improve lifecyle management of resources

[gterzian]

Proposed follow-up for #31995

I think there are two problems:

1. Too much individual IPC messages, and back and forth to free IDs, makes it hard to reason about what is going on, and I think also make clean shut down dependent on ignoring IPC channel errors(when the backend sends a free msg to script).
2. Drop of dom structs, see Drop impls for DOM types should be forbidden #26488

Instead I propose we centralize resource management, and loosely integrate with the DOM lifecyle.

We should centralize all logic around the gpu_id_hub, which is shared per global

servo/components/script/dom/globalscope.rs

Line 3087 in 81c4f2a

pub fn wgpu_id_hub(&self) -> Arc<Mutex<Identities>> {

and then used by dom struct to get new id, for example

servo/components/script/dom/gpudevice.rs

Line 633 in 81c4f2a

let bind_group_id = self

So the individual dom struct should not manage their own IDs, the global should keep some kind of map of id to weak ref of dom object(see weakref.rs).

Then, we can integrate the gpu_id_hub into perform_a_dom_garbage_collection_checkpoint, where we loop over all Ids, collect those that need to be freed, and then:

1. locally free them in script, and
2. send a single IPC message for all to freed in the backend(no need to send anything back, script already freed them).

[sagudev]

Cleanup usually goes something like this in firefox:

  if (!bridge) {
    return;
  }

  if (bridge->CanSend()) {
    bridge->SendBufferDrop(mId);
  }

  wgpu_client_free_buffer_id(bridge->GetClient(), mId);

so we can probably move id freeing to script completely.

IDEA: Instead of having global lock for all hubs it might be worth to have separate locks per each hub or even for each type we are assigning.

What if instead of cleaning up with GC we just use RC to keep id alive and then on drop we free their ids?

[gterzian]

so we can probably move id freeing to script completely.

Right.

What if instead of cleaning up with GC we just use RC to keep id alive and then on drop we free their ids?

The idea is to avoid using Drop, and also to batch all the freeing via the checkpoint.

IDEA: Instead of having global lock for all hubs it might be worth to have separate locks per each hub or even for each type we are assigning.

Maybe, if there is actual lock contention...