Previews, as seen when this build job started (57f1c4f):
WebGPU _{webgpu.idl | Explainer | Correspondence Reference}
WGSL _{grammar.js | wgsl.lalr.txt}

I would prefer we make the features not possible to request in core, i.e., it is an error to request float16-renderable on a core GPUAdapter in its call to requestDevice.

I think the features should be implicitly enabled on core devices and if you try to request them explicitly nothing should happen. I imagine this is how future feature levels would work as well.

If we error instead this breaks forward feature-level compatibility.

I would prefer we make the features not possible to request in core, i.e., it is an error to request float16-renderable on a core GPUAdapter in its call to requestDevice.

I think the features should be implicitly enabled on core devices and if you try to request them explicitly nothing should happen. I imagine this is how future feature levels would work as well.

If we error instead this breaks forward feature-level compatibility.

Sounds good to me. Do we need to change the wording for requiredFeatures in the core specification?

Currently, requesting a feature which the UA is not aware of results in failure.

Maybe distinguish between:

• this is a feature the UA is aware of and does not support -> failure
  compared to:
• this is a feature the UA is unaware of -> warning in case the feature name was incorrectly typed?

Thanks, Mike.

It is a design principle that a Compatibility mode app must also be a valid Core mode app, i.e., it should run without error in a UA which only supports Core. It's my understanding that any new limits and features must also exist in Core, otherwise a Compatibility mode app that requests those limits or features would error in said UA.

If the PR as written violates this, or doesn't make this clear, suggestions are more than welcome!

this means rgba16float canvas doesn't work in compat if float16-renderable doesn't exist. Not sure what reprocussions that causes.

It's my understanding that any new limits and features must also exist in Core, otherwise a Compatibility mode app that requests those limits or features would error in said UA.

I think we should make the features and limits which are only needed in compat mode only cause errors if not requested in compat mode.

If we don't do that and we discover a feature is needed for compatibility post v1 of the core WebGPU specification, we now potentially break all UAs by adding a feature to compat mode until the UA supports the new feature.

A website which adopts compat mode should not find itself less compatible on a UA which hasn't implemented compat, given core is moving to CR first independent of compat.

this means rgba16float canvas doesn't work in compat if float16-renderable doesn't exist. Not sure what reprocussions that causes.

I think it will be fine - just produce invalid textures - because we do GPUTextureDescriptor validation in configure() and getCurrentTexture()

This discussion about how compat features/limits should work is too complicated to figure out on this issue. I have filed #4987, let's please discuss there. (Hopefully there isn't some old issue about this topic that I'm missing - I think I have written on this topic before, but couldn't find where.)

There seems to be a slight mismatch of multisample support.
EXT_color_buffer_float:

... and the RGBA16F, R32F, RG32F and RGBA32F formats, for which they are only required to support creation of single sample renderbuffers.

multisample support of RGBA16F, R32F, RG32F and RGBA32F :
core: yes
compat gl: optional

Commenting here for potential discussion.

^ Just to clarify for discussion, this issue doesn't affect the baseline requirements/capabilities of compat, it only affects what exact capabilities can be in these two new extensions "float16-renderable" and "float32-renderable".

When you say "compat gl" do you mean "compat on gl" or "compat-profile OpenGL"?