Remove IDs and Registries

[nical]

This is a meta issue to describe the long-ish term vision for wgpu-core's resource management and track the steps towards it.

Registries and IDs

Internally, all wgpu-core resources are stored behind Arcs. Externally, they are exposed as non-clonable structs containing an ID which conceptually corresponds to a single reference to the Arc of a resource.

The goal

Instead of having wgpu public types wrap a non-clonabe ID, we would like them to wrap the Arc to the internal resource directly (and be clonable).

TODO

• Resolve cycles in wgpu-core using weak references #5120
• Remove remaining internal use of the IDs.
• Make wgpu-core less generic (brainstorm) #5124
• Rewrite the record-reply functionality Add back support for tracing (trace feature) to wgpu #5974
• Move ErrorSink into wgpu-core #8911
• (Firefox): Move the wgpu-core part of command recording out of the content process
• Move logic present in the Global's methods into methods on wgpu-core objects
• (Firefox): Stop providing the IDs during resource creation and do ID mapping in the gecko-side bindings.
• Remove the registries

Other Related Issues

• IDs of resources used in render bundles are not resolved until finish() #8234
• Tracing does not support render bundles #8837

[sagudev]

(Firefox): Stop providing the IDs during resource creation and do ID mapping in the gecko-side bindings.

How exactly would that look like? Would that be something like hashmap that would map id to Arc of wgpu object that would live in WebGPU thread?

I'm mostly asking for servo, as it would be nice to share ID mapping stuff.

[nical]

(Firefox): Stop providing the IDs during resource creation and do ID mapping in the gecko-side bindings.

How exactly would that look like? Would that be something like hashmap that would map id to Arc of wgpu object that would live in WebGPU thread?

Yes, that's the general idea. Depending on how you generate the IDs you could get away with arrays instead of hash maps (like wgpu-core currently does).