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

Do we need to add features for things that we know won't change (for example the proposed: texture-views, provoking-vertex-first, texture-depth-load, texture-depth-sample, texture-format-reinterpretation)? Or even for things that are not wildly available? I'm worried that the feature matrix is getting more and more complex (in theory, not in practice).

I guess it's probably ok in the end and it might work better from the spec's point of view as we won't need special handling for compat, only talk about if feature X exists then Y.

I wish we had a non-normative doc that can give devs a rough idea of how available features are (and maybe even common ranges for limits).

Do we need to add features for things that we know won't change (for example the proposed: texture-views, provoking-vertex-first, texture-depth-load, texture-depth-sample, texture-format-reinterpretation)? Or even for things that are not wildly available?

I haven't checked, but D3D11 might be able to support these features, even if OpenGL ES can't.

I'm worried that the feature matrix is getting more and more complex (in theory, not in practice).

It's a good point. The concern in the meeting was that folks might start using the Features we'd agreed upon (e.g., float32-renderable) in Compat code, and if Core-only browsers didn't add support to recognize them now, such content would break until a new version of the Core-only browser shipped. By naming them all now, we give ourselves the chance to ship the features in Compat in future without breaking Core-only browsers.

I guess it's probably ok in the end and it might work better from the spec's point of view as we won't need special handling for compat, only talk about if feature X exists then Y.

I wish we had a non-normative doc that can give devs a rough idea of how available features are (and maybe even common ranges for limits).

In addition to D3D11, there could also be Vulkan 1.0 devices that support Compat without supporting Core.

I'm worried that the feature matrix is getting more and more complex (in theory, not in practice).

I also don't love that, and am still a bit concerned that we need to commit to the granularity on a relatively short deadline. I'll put in a plug again for being able to defer these decisions if we use hasCompatibilityFeature()/requiredCompatibilityFeatures. 🙂

I also don't love that, and am still a bit concerned that we need to commit to the granularity on a relatively short deadline. I'll put in a plug again for being able to defer these decisions if we use hasCompatibilityFeature()/requiredCompatibilityFeatures. 🙂

We could prefer to be overly granular for now and remove features later before the compat specification reaches CR. There is little harm for example in saying we reserve K * 10 names for features but then only K make it into the specification.

I also don't love that, and am still a bit concerned that we need to commit to the granularity on a relatively short deadline. I'll put in a plug again for being able to defer these decisions if we use hasCompatibilityFeature()/requiredCompatibilityFeatures. 🙂

I worry that this is yet another wart that is going to be difficult to unship.

Also, I'm wondering how this scales to future featureLevels. E.g., for featureLevel Whizbang, Would we need to add hasWhizbangFeature() / requiredWhizbangFeatures()? Or is there something Compat-specific about this issue?

@SenorBlanco @kainino0x I suppose it is really necessary we know all the feature and limit names right now?

We do have readonly attribute DOMstring featureLevel; being added to the GPUAdapter in #5012 so a site could check the featureLevel prior to requesting certain compat features as a way to work around this issue? Then we can take our time with names for compat mode and any site which does run into this issue could be directed to featureLevel detection to workaround the browser not stating they support a compat feature which they should on core.

I worry that this is yet another wart that is going to be difficult to unship.

We would not unship hasCompatibilityFeature(). requiredCompatibilityFeature can be trivially unshipped since it is ignored on core adapters anyway.
IMO hasCompatibilityFeature() is a much smaller wart than 10ish feature names that will always show up in both adapter.features and device.features.

Also, I'm wondering how this scales to future featureLevels. E.g., for featureLevel Whizbang, Would we need to add hasWhizbangFeature() / requiredWhizbangFeatures()? Or is there something Compat-specific about this issue?

I think the analogous situation is we've already shipped whizbang and some browser is removing core by upgrading it to whizbang. However (1) all of the core-based features will already be using features/requiredFeatures so we can't consider moving them to hasCoreFeature()/requiredCoreFeatures and (2) all major browsers will have shipped core already so won't be shipping whizbang without having ever implemented core.

We do have readonly attribute DOMstring featureLevel; being added to the GPUAdapter in #5012 so a site could check the featureLevel prior to requesting certain compat features as a way to work around this issue? Then we can take our time with names for compat mode and any site which does run into this issue could be directed to featureLevel detection to workaround the browser not stating they support a compat feature which they should on core.

I don't think this adds anything. Technically that pattern works for the situation where safari ships core before chrome ships compat, but (as someone other than me pointed out) there's also the situation where chrome has already shipped compat and wants to add some new more-fine-grained compat feature. This won't work during the transition period where both old and new instances of chrome are running in the wild.

Anyway, I don't think there's any need for this. If we're relying on sites to get it right anyway, they should just check adapter.features.has('late-breaking-compat-feature') before setting requiredFeatures: ['late-breaking-compat-feature']. This works in both situations, and we tell people to do this already, and we enforce it by rejecting requestDevice() to indicate a programming error.

hasCompatibilityFeature()/requiredCompatibilityFeatures retains the portability risk for old vs new chrome, but eliminates the portability risk of chrome vs safari (for this specific problem). I think.

@SenorBlanco @kainino0x I suppose it is really necessary we know all the feature and limit names right now?

We do have readonly attribute DOMstring featureLevel; being added to the GPUAdapter in #5012 so a site could check the featureLevel prior to requesting certain compat features as a way to work around this issue? Then we can take our time with names for compat mode and any site which does run into this issue could be directed to featureLevel detection to workaround the browser not stating they support a compat feature which they should on core.

Sure. If we're ok with relying on Compat applications to do feature detection via adapter.featureLevel == 'core' || features.has('feature') in the interim, there's no rush to name the features. We can discuss it in upcoming meetings.

this can be closed yes?