Description
A proposal for the behavior of object labels has been accepted in the WebGPU group:
gpuweb/gpuweb#3263 (comment)
There are 2 key things here:
- In cases where there are multiple wrappers for the same object (e.g. getBindGroupLayout, or internally-deduplicated objects), each wrapper maintains its own copy of the label.
- How the label is used is implementation-defined, but the design enables implementations to keep track of all of the labels currently associated with an internal object (internally
ReplaceLabelorAddLabel/RemoveLabel), so that we never have to mislead developers about what an object is. For example, if yougetBindGroupLayouttwice, set the labels tooneandtwo, an error message might say something like... isn't compatible with binding 0 of [BindGroupLayout "one|two"].
In webgpu.h, there are not guaranteed to be wrappers - e.g. createBindGroupLayout can return the exact same pointer value multiple times due to deduplication. This means when you SetLabel in a native implementation it might replace labels on bind group layouts that just happened to be identical. So, should we have a ReplaceLabel(old,new) or AddLabel(new)/RemoveLabel(old) API in webgpu.h instead? But there's a major problem here, I think - in both cases, we would also "leak" labels when you free an object ref, because we wouldn't know which label belonged to that ref, unless we require the label on free, which seems like a non-starter. (If we did, we could perfectly maintain the label list.)
I'd conclude that webgpu.h still needs a SetLabel API, despite the label fidelity problem. Some applications may want better fidelity. They could achieve this either by using an extension Replace/Add/Remove API (which e.g. Chromium would use), or maybe by enabling a special implementation mode that disables object deduplication, or adds an indirection layer to match the JS API (e.g. tracking labels in dawn wire)?
We also need to be able to implement webgpu.h on top of the JS API. SetLabel maps most nicely, since it simply overwrites the label of the wrapper.
Aside on how to implement Replace/Add/RemoveLabel on Emscripten
ReplaceLabel is interesting, because Emscripten can check (in debug builds) that the old label matches before overwriting the label, ensuring we always remove one label and add one label. AddLabel/RemoveLabel would need to be implemented as an additional layer on top of JS labels, though perhaps this is fine. Imagine a WASM application adds labels "one" and "two" and Dawn deduplicates it with an object with label "other": internally, the label could become e.g. one+two|other, if + were used by Emscripten and | by Dawn.