wgpu_is_valid_object does not validate the underlying dawn object in lib_webgpu_dawn.cpp

[DavidMohrhardt]

It seems the function implementation for wgpu_is_valid_object only checks to see if the handle is valid and whether the handle has been registered to the object table but not whether the underlying .dawnObject is valid. This behavior seems incongruous with the name of the function and I wanna double check whether this is the intended behavior.

[juj]

That is an interesting question.

the function implementation for wgpu_is_valid_object only checks to see if the handle is valid and whether the handle has been registered to the object table

This is true.

Going over the WebIDL spec, it does not seem like there exists a JavaScript-exposed function call that would allow querying whether an object handle is valid for its .dawnObject handle. That seems like an internal browser implementation detail.

Or do you have a specific JS function in mind that would be possible to use to detect this?

[juj]

Err, re-reading this, I now realize I interpreted the question completely in the wrong scope - my mindset was that this would have related to the JS function.. but of course the title already states that this pertains to lib_webgpu_dawn.cpp native implementation. So my comment was of course total garbage here.

CC @brendan-duncan if he has an idea, he's been working closer in the dawn implementation.

[brendan-duncan]

I think the question of wgpu_is_valid_object would be applicable to both JS and dawn backends. But I don't think there is a good answer, it's something missing from the WebGPU spec to determine if an underlying object is valid or not. It's frustrating that the only way to track this is via error scopes, which can add enough overhead they shouldn't be used in anything that's even of moderate frequency. So if there was an error creating a render pipeline, for example, it can result in spamming of error messages in the console trying to use an invalid render pipeline as there's not really an efficient way to track object validity.

Error scopes were supposed to be an improvement on the state flush stalls of glError, but they still have overhead where we can't use them in many places.