Most objects have no way of setting their label

[litherum]

Compute pipelines, render pipelines, and shader modules are the only objects which have a way to set their label. However, in WebGPU, almost all objects have settable labels.

[Kangz]

Right now in Dawn we started adding some wgpu::<Object>::SetLabel methods, but adding a method to each object like this would make the API have a lot more functions for little additional use. WDYT of a wgpuObjectSetLabel(void* object, const char* label)? It would do a dynamic dispatch on the object type internally, but it's a pretty cold function so it should be fine. @kvark: would this work with wgpu-rs's handle architecture?

WDYT @kvark @austinEng @kainino0x ?

[kainino0x]

Seems OK to me. Couldn't it be done without dynamic dispatch (at least in C++) since the label field and the SetLabel method could both be on a base object?

I really wonder if we could do the same with memory management (#15 #94 #100).

[kainino0x]

Seems OK to me. Couldn't it be done without dynamic dispatch (at least in C++) since the label field and the SetLabel method could both be on a base object?

Oh we would still need dynamic dispatch (or something) in order to pass the label to the driver, though browser don't have to do this by default. In any case a virtual function call in setLabel seems like a non-concern to me.

For reference/release though, I think it could still work. (Reference/release would be non-virtual, only the destructor would be virtual.)

[Kangz]

@kvark or @cwfitzgerald any opinion on this from the wgpu side?

[kvark]

We don't store anything like an "object type" inside objects. The type has to be known.
Does this particular issue motivate use to invent this? No, I wouldn't consider this to be that important.

Now, if we are talking about a bigger picture with reference/release done this way, that's a better motivator. Our longer term plan was to have object ID be Arc<SomeObject> for some object and Box<OtherObject> for others. So we'll probably need to dispatch any type-id related calls internally.

This is a possible direction, but it's very different from the current way C API is built. I don't think the inconsistency is worth it.
Perhaps, @kainino0x can follow up by writing a more concrete proposal on the reference/release, and we can block on that.

[Kangz]

Does this particular issue motivate use to invent this? No, I wouldn't consider this to be that important.

If you implementation happened to have type information then it would have been easy to choose to make a generic function to set the label. Adding 20 functions just for this is a bit ugly but ultimately ok.

Perhaps, @kainino0x can follow up by writing a more concrete proposal on the reference/release, and we can block on that.

I updated #15, but not with a generic function. I could do that if you're interested (with generic ref/release).

[kainino0x]

Perhaps, @kainino0x can follow up by writing a more concrete proposal on the reference/release, and we can block on that.

I don't think there's anything to it, all of the detail is in the implementation.

wgpuObjectReference(void* object);
wgpuObjectRelease(void* object);

[kvark]

@kainino0x this could be tricky in a situation where some objects are Arc<> and others as Box<>.

[kainino0x]

Ah yeah, this would of course only work (well) in a design where everything was going to have a Reference and Release method anyway.

[kainino0x]

I think the conclusion here was we just need separate SetLabel, Reference, and Release for every object. Marking "has resoultion"

(See also #167)

[litherum]

This is done.