-
Notifications
You must be signed in to change notification settings - Fork 335
[Process] Add RequirementsForAdditionalFunctionality.md #2424
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Process] Add RequirementsForAdditionalFunctionality.md #2424
Conversation
|
||
## Glossary | ||
|
||
- "Browser engine" means "(Blink and Dawn) / (Gecko and wgpu (and maybe more?)) / (WebKit and WebGPU.framework) / etc." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can remove the "and maybe more?" bit, since there is /etc
at the end.
Were you thinking of Servo or Deno here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, no, I was thinking that Gecko seems to be using a constellation of frameworks/libraries inside it which all contribute to WebGPU. That constellation, taken together, should be considered a single browser engine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, ok. Describing it as "Gecko and wgpu" is totally fair. The only other significant thing in the constellation is "naga". Whether it's listed here or not doesn't matter too much, but should be consistent with listing Tint alongside of Dawn.
- Adding anything in the WebGPU Github Team / Project / Wiki / Organization / etc. | ||
- Mere discussion within the CG / WG official meetings. | ||
|
||
## Requirements |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very nice list here
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 |
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:
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:
|
There are 2 reasons for this document:
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.
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.
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.)
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.
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?
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?
OK
Right.
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.)
I think this is what the document already says. (I'm happy to update the PR to include any missing vendors.)
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.
|
a5abb54
to
f6dc7c8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good statement of our current decision/qualification requirements.
Because I feel that we have a healthy understanding of and consensus around these principles, it feels a little weird to me to draw them up formally.
While I have concerns that being clear about criteria invites optimization and workarounds around said criteria, it's probably helpful to include something like this as an on-ramp for anyone unfamiliar with our operating philosophies.
I don't see this doc as newly-binding, so much as a recitation of our operating principles, which are of course potentially mutable to some future new consensus.
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.
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.
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.
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. |
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. |
WebGPU meeting minutes 2022-03-09
|
Resolution today: Merge as is. Any updates will be made as follow-up PRs. |
WebGPU meeting minutes 2022-03-16
|
I believe this matches the consensus in the group from the call regarding this issue.
We have a few follow-up changes we'd like to propose, but rather than lumping the new things in with the old, we figure it would be beneficial to first commit what (I believe) the group has consensus on, before proposing changes to it.