Add WebGPUDebugLabel mixin and label to relevant dictionaries - #126

Note this doesn't change any behaviour. It's just for exposure in tooling.

We were just discussing how this should be exposed for all objects on #121. See my comment there about the timing - does setting the attribute "enqueue" an operation? Or is it somehow instantaneous?

Yeah, each object should have a label - so ignore this pull request until I update it.

does setting the attribute "enqueue" an operation? Or is it somehow instantaneous?

I don't see any reason why it needs to enqueue an operation. In our implementation we'll probably label everything with a unique id, and map that back to what the API exposes.

Setting the name in JS can't instantaneously set the Metal label without a synchronous IPC round-trip in Chrome.

If you label everything with a unique id purely on the backend, Xcode would show the unique id, rather than the user's custom label; how would it get mapped back?

I'm talking about the browser-side tools.

But yes, if you use the platform tools, then you'll need to know the mapping somehow. I'd probably expose this also from browser developer tools, or some kind of internal logging.

It seems worth having it this way to avoid touching the platform label.

For browser side tools, I'd be fine with having it be instantaneous.

Sorry, I got confused and thought you were going to propagate the debug labels down to the Metal level. That is also something I think we ought to do.

OK. Updated the pull request and changed the title. I believe this addresses #121, with the exception of the resource naming. Metal doesn't support this directly, but I'm not against including it.

I was tempted to have the relevant dictionaries inherit from a base dictionary with a label field, but I think it was nicer to have all the debugging stuff in one place at the end of the document.

This pull request made it so you can modify the object label after it has been created. Is it on purpose? The alternative of putting a name in the descriptors used to create objects seems simpler.

@Kangz every tiny little divergence that WebGPU makes from native platforms is going to really annoy platform developers. Since every platform already allows changing modifying object label after it is created (and shipping game engines definitely already rely on this), making this immutable probably makes the implementation simpler but at the huge cost of annoying porting developers.

The debugging layer is where you would most want to fight for platform developer convenience over API purity. In my own engine, built from scratch in JavaScript designed for WebGPU, it would be a pain to thread that name all the way through to the creation-time descriptor, given the amount of code in the way. Developers will be adding in those resource name sets everywhere in debugging code. Allowing them to debug quickly and efficiently is very much worth the slight implementer inconvenience.

@magcius I very much agree with you and if naming after creation is what engine do today, they should still be able to do it on the Web. However WebGPU has a chance to be opinionated and push people to do things a certain way. It'd be nice to have both ways to set the name but say that setting it at creation time "is the better way". Maybe by having the post-creation way be a universally implemented extension?

Note that the implementation cost is almost zero for both solutions.

I, personally, would save my opinions for things that have high implementation costs. I'm all for being opinionated in cases where it matters (e.g. everyone is aware that OpenGL code is difficult to properly write because it is not very opinionated and you can easily get put on a slow path), but debugging is one of those cases where the user needs all the flexibility and help they can get.

(to be clear, I meant the implementation cost on the browser side)