Remove GPUDevice.{adapter,features,limits} - #1309

Previews, as seen at the time of posting this comment:
WebGPU | IDL
WGSL
_4ade04a

I actually would love to see us go the other way on offering reflection of e.g. parent objects. It's such a great quality-of-life thing, and I use it all the time e.g. WebGLRenderingContext.canvas.width = N. We already have this info internally, and I think it makes life better if we just expose it. Every shim library I've written ends up injecting parent references, but has to go through extra function hooking shenanigans to make it happen, so this would make things simpler and more robust for that usage too.

Worth noting that having this sort of reflection (e.g. GetDesc) is something that generally makes D3D nicer to work with than other less "reflective" APIs.

It seems like having this reflection shouldn't make specification any harder than having them be hidden, other than the boilerplate specification of "here's a readonly accessor".

Honestly I might be fine with adding reflection of the provided parent object (e.g. texture.device or view.texture) and descriptor (though unfortunately it adds some unavoidable client side memory cost). All of our descriptor info is immutable so it makes it relatively tractable to do so. It also technically provides a (very late) feature detection for what members of a descriptor were recognized by the browser (but we're trying hard to never introduce something where this would be a problem).

• Do we want parent pointers?

I'd love us to have a solid and consistent approach here. If we want to expose the parents, and do it for all objects, that seems fine, since it's self-contained. But if we expose the BufferDescriptor but not BindGroupDescriptor, that begs a question "why". And sooner or later SpectreJs comes to us and asks for the latter after getting the former.

Another aspect to keep in mind is what the effect of this is on webgpu-native. Keeping an extra link or two per object may have a stronger effect than it does on the Web.

I think webgpu-native can make this decision independently. But as long as we have weakrefs then we still avoid cycles.

Honestly I might be fine with adding reflection of the ... descriptor

One thing to keep in mind: descriptors are dictionaries, and any unknown keys are ignored. If we're going to retain these descriptors, we'll have to decide whether we want to retain the unknown keys or not.

Also, any version of retaining the descriptors has to do a deep copy instead of a shallow copy, because we don't want JS modifying a dictionary after the fact to change the object's reported characteristics. Therefore, if we want to retain those objects, we might have to say like "we'll only do a deep copy of the object if its shallowclonable (or whatever) and if it's not we'll do a shallow copy." But this is getting into a world of hurt. I wish we could just ignore unknown keys (and misparsed values)

(Also, the CSS Font Loading API discards unknown keys.)

There's also another benefit to returning the parsed values - web authors can figure out what the browser accepts and what it doesn't, in order to have fallback logic. I'm not sure how much value this would have in WebGPU specifically, where I think we're encouraging authors to do this fallback at the extension level and not at the individual function call level... but this approach of "round-trip stuff through the browser to see what it understands" is at least idiomatic JavaScript.

I agree we would not retain unknown keys. Since the create methods take dictionaries, the original object and extra keys are invisible to us. This applies recursively to dictionary and sequence types. Reference types (interface, object, any) would need to keep pointing to the same JS wrapper, but we don't have many of those. (And I would imagine not doing reflection for e.g. bind group internals.)

Editors discussed and decided that GPUDevice.features and .limits are useful for a lot of stuff, and we should keep them. I'll open a separate PR to remove .adapter.