Previews, as seen when this build job started (a5abb54):
WebGPU | IDL
WGSL
Explainer

Thank you for putting this PR up. I'd like to have an opportunity to discuss this internally with other Google participants before posting here, so this will most certainly push the discussion in the new year.

@Kangz ping

@Kangz ping

Sorry for the delay. Here are some results from our internal discussion (with apologies if this is colored by my own preferences; I didn't have it reviewed beforehand).

Firstly, we would like to better understand the intent of this document (and have it be clearer about its intent). We don't fully understand why it's important to define these criteria right now, although we do see the value generally and agree with adding guidelines like these as the group shifts more into a new-feature working mode.

A few clarifying stances:

• Web technology is not just limited to browsers. JS engines and pseudo-browsers like Deno and Electron build a lot of functionality on Web technology.
• We shouldn't allow any single participant in the group to shut down a proposal that's supported by other members of the group. I don't think that was the intent of this document, but it's important to clarify.
• We don't want situations where WebGPU can't progress because another spec is not "standards track" or vice versa (WebGPU has many interop points; cases in point: WebCodecs, WebNN).

We would like to have better terminology around "standardization". To me, standardization can occur when there's a document describing behavior implemented or accepted by multiple implementations. We need a word, e.g. "ratified", for features included in the main WebGPU/WGSL specs, which is more substantial than the group simply producing documents. We understand that development of new proposals could take place outside this group and (optionally) be brought to it later, but we see great value in having a well-known forum for developing both ratification-track and non-ratification-track proposals: WebGPU-Compat, raytracing, pipeline statistics (#2301), etc. In particular, we would not want to apply the criteria of this document to exploratory or pre-ratification work being done inside the group.

Now, on this document:

This process document would be an artifact of the group, and we think that it should not try to restrict the behavior of the group, but describe predefined criteria under which the group can make decisions. That is, the group could decide to reject a proposal based on these criteria, but we wouldn't be obligated to do so. The document should be less authoritative than the group (we wouldn't make it part of the charter).

If the document is less authoritative, it can be more strict (and precisely codify our actual current practice) - retaining the explicit intent to keep it up to date over time. My proposed tweaks to the requirements:

• Implementable in all three of Blink/Gecko/WebKit, in the opinions of those engines' representatives.
  • note: "Implementable" is inherently subjective, as anything "can" be implemented with enough software, so explicitly defer to the representatives.
  • note: I think it's OK to not include Node/Deno here - they can use "extensions" that are not "standardized"[EDIT: /"ratified"]; see above.
• Implementable on all three of D3D/Vulkan/Metal (latest versions with extensions).
  • note: There's an expectation that we will bypass this; for example, ETC2 is not available on D3D, but we still specify it because it's part of the BC/ETC2/ASTC family.
• Implementable on GPU designs from any two of Intel/AMD/NVIDIA/Apple/Qualcomm/ARM/Imagination/VeriSilicon.
  • note: This tries to be a complete list but I'm sure it isn't. This list could remain open instead of being fully specified, but not necessary because we can choose to bypass it.
• Positively impacts a "substantial" number of users.
  • note: Added this just to make it clear we are likely not to accept extremely niche proposals.

@Kangz ping

Sorry for the delay. Here are some results from our internal discussion (with apologies if this is colored by my own preferences; I didn't have it reviewed beforehand).

Firstly, we would like to better understand the intent of this document (and have it be clearer about its intent). We don't fully understand why it's important to define these criteria right now, although we do see the value generally and agree with adding guidelines like these as the group shifts more into a new-feature working mode.

There are 2 reasons for this document:

1. The more extensions the CG makes, the more difficult it will be to develop on WebGPU. It would be very unfortunate if we had hundreds of orthogonal extensions, making each developer implement gazillions of codepaths to cover a wide variety of devices.
2. To protect the device / vendor / browser independence of the web. The fact that the web in general works (pretty much) the same way on all devices is one of the keys to the web's success. Developers shouldn't have to implement the same feature, once for AMD ray tracing and once for Nvidia ray tracing, or once for DirectX VRR and once for Vulkan VRR, or once for Metal tessellation and once for DirectX tessellation, etc.

A few clarifying stances:

• Web technology is not just limited to browsers. JS engines and pseudo-browsers like Deno and Electron build a lot of functionality on Web technology.

Deno and Electron do not browse the open web, though, and thus have very different compatibility concerns. If Deno or Electron want to make their own nonstandard extension to WebGPU, without proposing it to this CG, they can go right ahead. There are tons of nonstandard node.js modules.

• We shouldn't allow any single participant in the group to shut down a proposal that's supported by other members of the group. I don't think that was the intent of this document, but it's important to clarify.

Web standards bodies are run by consensus; any member can make a formal objection to any proposal, regardless of the document in this pull request.

• We don't want situations where WebGPU can't progress because another spec is not "standards track" or vice versa (WebGPU has many interop points; cases in point: WebCodecs, WebNN).

I believe WebCodecs and WebNN are both on the standards track. (This isn't a statement about implementation desire in any particular browser, or authors' desire to use these things; it's just a statement about how the CGs/WGs creating those documents desire to produce W3C Recommendation documents eventually.)

We would like to have better terminology around "standardization". To me, standardization can occur when there's a document describing behavior implemented or accepted by multiple implementations. We need a word, e.g. "ratified", for features included in the main WebGPU/WGSL specs, which is more substantial than the group simply producing documents. We understand that development of new proposals could take place outside this group and (optionally) be brought to it later, but we see great value in having a well-known forum for developing both ratification-track and non-ratification-track proposals: WebGPU-Compat, raytracing, pipeline statistics (#2301), etc. In particular, we would not want to apply the criteria of this document to exploratory or pre-ratification work being done inside the group.

I think there's a misunderstanding about this document. Exploratory or pre-"ratification" work abides by this document as long as it aspires to eventually land in multiple browsers, on multiple devices, and on multiple APIs.

On the other hand, if we had an AGX-specific feature that we knew would never be implemented on any other vendor's devices, and we never intended for it to be implemented elsewhere, such a feature does not belong in WebGPU.

Now, on this document:

This process document would be an artifact of the group, and we think that it should not try to restrict the behavior of the group, but describe predefined criteria under which the group can make decisions. That is, the group could decide to reject a proposal based on these criteria, but we wouldn't be obligated to do so. The document should be less authoritative than the group (we wouldn't make it part of the charter).

Right, we're definitely not proposing modifying the charter.

"the group could decide to reject a proposal based on these criteria, but we wouldn't be obligated to do so" Can you give an example where you believe the group should not reject a single-vendor, single-browser, or single-API feature?

If the document is less authoritative, it can be more strict (and precisely codify our actual current practice) - retaining the explicit intent to keep it up to date over time. My proposed tweaks to the requirements:

• Implementable in all three of Blink/Gecko/WebKit, in the opinions of those engines' representatives.

I think I agree with the spirit of this, but probably not with naming specific browsers. What happens if Vivaldi decides they want to implement WebGPU?

• note: "Implementable" is inherently subjective, as anything "can" be implemented with enough software, so explicitly defer to the representatives.

OK

• note: I think it's OK to not include Node/Deno here - they can use "extensions" that are not "standardized"[EDIT: /"ratified"]; see above.

Right.

• Implementable on all three of D3D/Vulkan/Metal (latest versions with extensions).

I'm not so sure about this. We actually have a proposal that's coming as an additional modification on top of this document (read: an additional pull request after this one) which gets at this topic, but from a different angle.

At the risk of spoilers, we believe that it's okay for WebGPU to have a feature only supported by 2 APIs, as long as the 3rd API doesn't natively also have facilities for that same feature. If someone proposes feature X to WebGPU, and one of the APIs has feature X, then the WebGPU feature better run on that API using its native feature X. (But this is a discussion for a subsequent PR; I'd recommend deferring this specific discussion until that time.)

• note: There's an expectation that we will bypass this; for example, ETC2 is not available on D3D, but we still specify it because it's part of the BC/ETC2/ASTC family.
• Implementable on GPU designs from any two of Intel/AMD/NVIDIA/Apple/Qualcomm/ARM/Imagination/VeriSilicon.

I think this is what the document already says. (I'm happy to update the PR to include any missing vendors.)

• note: This tries to be a complete list but I'm sure it isn't. This list could remain open instead of being fully specified, but not necessary because we can choose to bypass it.
• Positively impacts a "substantial" number of users.

I think I disagree with this. The number of users can certainly affect prioritization of a proposal, but I don't think it's sufficient for a rejection of a proposal. One example might be if a certain proposed feature might be really really useful for people with a specific physical disability; the number of such users might not be large, but the feature might still be quite important.

• note: Added this just to make it clear we are likely not to accept extremely niche proposals.

Previews, as seen when this build job started (f6dc7c8):
WebGPU | IDL
WGSL
Explainer

I think I agree with the spirit of this, but probably not with naming specific browsers. What happens if Vivaldi decides they want to implement WebGPU?

Vivaldi also uses Blink, and I'm not aware of any other maintained browser products that use an engine other than these 3. But it would be apparent to the group if such a situation arose and this document needed to be updated.

"the group could decide to reject a proposal based on these criteria, but we wouldn't be obligated to do so" Can you give an example where you believe the group should not reject a single-vendor, single-browser, or single-API feature?

No, and I'd guess one would never exist. That's not my point though; the document shouldn't be written as if it constrains the behavior of the group, when it does not.

I'm not so sure about this. We actually have a proposal that's coming as an additional modification on top of this document (read: an additional pull request after this one) which gets at this topic, but from a different angle.

At the risk of spoilers, we believe that it's okay for WebGPU to have a feature only supported by 2 APIs, as long as the 3rd API doesn't natively also have facilities for that same feature. If someone proposes feature X to WebGPU, and one of the APIs has feature X, then the WebGPU feature better run on that API using its native feature X. (But this is a discussion for a subsequent PR; I'd recommend deferring this specific discussion until that time.)

This case clearly requires further details/discussion, after which the group needs to explicitly make the call that it's OK to ship something that violates these guidelines (because it reaches only 2 APIs), which is exactly the process I think we should have and the role I think this document should play.

I think I disagree with this. The number of users can certainly affect prioritization of a proposal, but I don't think it's sufficient for a rejection of a proposal. One example might be if a certain proposed feature might be really really useful for people with a specific physical disability; the number of such users might not be large, but the feature might still be quite important.

You're right, "substantial number of users" is definitely not the right wording. It's more "has a substantial positive impact on users" but I don't know what the right wording is.

I think I agree with the spirit of this, but probably not with naming specific browsers. What happens if Vivaldi decides they want to implement WebGPU?

Vivaldi also uses Blink, and I'm not aware of any other maintained browser products that use an engine other than these 3. But it would be apparent to the group if such a situation arose and this document needed to be updated.

That said, I'm fine with the language currently in this PR (for both browser engines and hardware vendors), as this is a somewhat blurry line anyway that will come to the attention of the community group on a case-by-case basis.

Resolution today: Merge as is. Any updates will be made as follow-up PRs.