Blink signal carve-out for WebGPU

[Corentin Wallez]

TL;DR: Firefox and Safari are very active in the WebGPU group, and items landing in the WebGPU spec are similar to stage 3 in WASM/JS group. Could we have a Blink-signals / I2S carveout / shortcut to avoid process overhead and spamming blink-dev. I could join one of the weekly meetings to discuss this "in person" if need be.

Hey all,

For context I'm the TL of WebGPU at Google and co-chair of the "GPU for the Web" W3C CG/WG that makes WebGPU and WGSL

Now that the first version of the WebGPU specification has been shipped in Chromium, the "GPU for the Web" working group has shifted to a mode where the WebGPU specification is a living spec. This means that new developer-visible features are added to the spec continuously and that browsers will implement them at their pace. The group collectively agreed to not start adding large features to let other implementations catch up, but is ok adding small polish features that were basically missed in the first shipped version. So over the coming month the W3C group is looking to resolve / add functionality for all of the Milestone 1 items over the coming months.

This means that we will soon be sending an increasing number of I2S to blink-dev, there has been a few already, a PSA, another I2S for shader-f16, and more. That's without counting the developer-visible changes that were accidentally shipped without notifying blink-dev (we want to do better, in part why I'm starting this thread).

Each I2S takes a bunch of time to prepare, especially for folks not used to the process. Gathering all the signals can be difficult when it's just a nod buried from another implementation's representative in the WebGPU meeting. Then getting the LGTMs can take time, both in latency to get the approvals, and for the Blink API owners to review the feature, signals, etc.

go/why-standards, and in general the Intent to Ship process is here for Eventual Interoperability, Consistency and Transparency. 

Eventual interoperability: the WebGPU/WGSL group is acting in an extremely collaborative way compared to what can happen in other specifications. Both Firefox and Safari are actively implementing, they actively discuss all proposals and approve them directly (not just as a stamp, but being really engaged). This means that things that go in the spec will be eventually interoperable. Otherwise it just doesn't land in the specification.

Consistency is normally enforced by the TAG and other horizontal reviews, and the WebGPU group diligently went through all the horizontal reviews. We didn't get much actionable feedback, which is understandable given how large WebGPU is, how domain-specific it is, and that so many very Web platform savvy folks participated (in particular from Apple at the start of the standardization). That's why WebGPU is unlikely to file for more horizontal review for additional features, unless extremely large, or with a large interaction with the rest of the Web platform (features like multi-worker, WebXR, and maybe some others would qualify).

Transparency: this is where we want to do better, for example with sending PSAs that collectively contain all the developer facing changes.

Because of all of the above we believe that most WebGPU developer facing changes don't need as careful a review. We'd like to suggest that most small-medium changes landing in the spec that don't interact with the rest of the Web platform should ideally just need a PSA sent to blink-dev. Other larger, or more "interesting" features should still get an I2S, but the change being landed in the WebGPU spec should count as a positive signal from other implementations.

If need be, I'd be happy to provide more details / discussion by attending one of the weekly Blink API owners meetings, for example the one October 18th.

Cheers,

Corentin

[Chris Wilson]

The primary reason we've been comfortable with a carve-out for Javascript and WASM is the stages mechanism, that by agreement with the other implementers is a clear indication of their support.  Has the WebGPU WG had this conversation, or have you had it, with the other implementers?  What would Mozilla and Apple think of using Milestone 1 as the indicator of their support?  (and what does the process look like for deciding things go into Milestone 1?)

As another aside - in browsing around for a while, the status of the spec itself seems a bit unclear; there's an up-to-date TR that seems to be a frequent snapshot of the editor's drafts - but the editor drafts are listed as work product of the CG, not the WG, which is a little odd.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAGdfWNO1q9%3DaTMf6Nrnc%2B8TiwTe5Y6Wnub5nqJkFNWy%3D8XVhVA%40mail.gmail.com.

[Ken Russell]

Including +Brandon Jones, WebGPU spec co-editor, in this discussion so that he can comment. To the best of my understanding, the WebGPU community and working groups were structured similarly to Wasm's - most of the discussion happens in the lower-overhead CG, and snapshots are periodically signed off by the formal WG. Presence of a feature even in the WebGPU editor's draft indicates that consensus was already reached among Chromium, Firefox and WebKit leaders. We wouldn't want to tie Blink's support signals to specific WebGPU milestones like Milestone 1; the intent is to keep those milestones rolling forward. I defer to Corentin's and Brandon's analyses, though.

--

I support flexible work schedules, and I’m sending this email now because it is within the hours I’m working today.  Please do not feel obliged to reply straight away - I understand that you will reply during the hours you work, which may not match mine. (credit: jparent@)

[Alex Russell]

A big concern for the API OWNERS is preventing "bikeshed after shipping" situation where second (or third) movers who did not do the work to build or ship cause well-intentioned API developers to agree to breakage after we've agreed to I2S. This is a bad pattern, and one of the reasons we've become comfortable with the WASM and TC39 stages processes as proxies is that they explicitly avoid breakage in shipped implementations.

WebGPU is relatively new, but I'd be open to a trial period for some set of changes (assuming they're still signposted to blink-dev, perhaps in a batch). In this formulation, breaking changes post-shipping in Chromium would revoke the license to operate more independently.

Is that reasonable from your perspective? Are you aware of breaking proposals in the last year?

Best,

Alex

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAMYvS2eGaHF7Seet0peLyR5PV7nbZtdicsNRjxxUTfaqe%2BA%3DCQ%40mail.gmail.com.

[Chris Wilson]

For WASM and TC39, we've explicitly asked the question in the past of Mozilla (and Apple too, I think, though I don't explicitly remember) "is stage 3 a good enough stand-in for your standards position?"  (i.e.: do we even need to ask for a standards position if it's made it to stage 3), and we got a clear "stage 3 is good enough; you don't need to ask further" answer.  (I'm paraphrasing pretty heavily here, obviously.)  As long as Mozilla and Apple agree that WebGPU has a clear indicator of their support, I think having a signals carve-out like stage 3 WASM/TC39 is fine.

This should only mean we don't need to gather vendor signals, though - the rest of the process should still be followed (i.e. there should be features filed in Chromestatus, I2S sent, etc.) in my opinion.  That process drives other things like feature announcement.

[Corentin Wallez]

Hey all,

Thank you all for being potentially open to this idea, and it seems very reasonable! Thank you also for detailing the concern about "bikeshed after shipping", it makes a lot of sense and we definitely want to avoid this issue. I can work with Firefox and WebKit to have some form of "stage" mechanism as well. Or at least agreement that things landing in specs after approval in a meeting with all parties involved means that after there are shipping implementations, they shouldn't be broken. If we had this, then the WebGPU folks would break down interactions with blink-dev as such:

• A grouped PSA for minor features where completely confident there won't be any risk. Examples are:
• Addition of trivial enums like sent earlier on blink-dev. 
• Non-breaking changes that make more WebGPU calls allowed, for example this PR after approval from other vendors.
• Similarly minor, non-breaking changes to WGSL.
• Intent to implement and ship, with implicit signals (if Firefox and WebKit agree to this in the W3C group) for medium size features, for example:
• WebGPU shader-f16 (though on this one we have signals, which is important since we didn't agree to a "stage" mechanism yet).
• Dual-source-blending once the names bikeshed in the group, and landed in the spec.
• Regular process for large features, or any feature that might carry an interop/bikeshed risk (these will likely to the TAG as well). For example WebGPU compatibility mode.

In the past there has been a single breaking change, and it was bundled in the release that turned WebGPU from an OT into a shipped API: Remove WebGPU limit maxFragmentCombinedOutputResources. And recently in the group there were discussions about potentially changing the semantic of a few things which quickly turned into "maybe potential future addition" once folks remembered WebGPU is a shipped API now.

Ideally we can skip the chromestatus features because it takes some time to fill the form and engineers are often puzzled by what they should fill (I have been, multiple times), but if it drives other tooling then we can make an how-to specifically for the WebGPU team on how to do this for the "minor features". What is driven by the I2S email?

Cheers,

Corentin

[Alex Russell]

I'm with Chris that we probably shouldn't be skipping the Status entries; it's important for us all to understand what has shipped.

[Johnny Stenback]

Hey Corentin,

On Tue, Oct 10, 2023 at 7:49 AM 'Corentin Wallez' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

Hey all,

Thank you all for being potentially open to this idea, and it seems very reasonable! Thank you also for detailing the concern about "bikeshed after shipping", it makes a lot of sense and we definitely want to avoid this issue. I can work with Firefox and WebKit to have some form of "stage" mechanism as well. Or at least agreement that things landing in specs after approval in a meeting with all parties involved means that after there are shipping implementations, they shouldn't be broken. If we had this, then the WebGPU folks would break down interactions with blink-dev as such:

• A grouped PSA for minor features where completely confident there won't be any risk. Examples are:
• Addition of trivial enums like sent earlier on blink-dev. 
• Non-breaking changes that make more WebGPU calls allowed, for example this PR after approval from other vendors.
• Similarly minor, non-breaking changes to WGSL.
• Intent to implement and ship, with implicit signals (if Firefox and WebKit agree to this in the W3C group) for medium size features, for example:
• WebGPU shader-f16 (though on this one we have signals, which is important since we didn't agree to a "stage" mechanism yet).
• Dual-source-blending once the names bikeshed in the group, and landed in the spec.
• Regular process for large features, or any feature that might carry an interop/bikeshed risk (these will likely to the TAG as well). For example WebGPU compatibility mode.

In the past there has been a single breaking change, and it was bundled in the release that turned WebGPU from an OT into a shipped API: Remove WebGPU limit maxFragmentCombinedOutputResources. And recently in the group there were discussions about potentially changing the semantic of a few things which quickly turned into "maybe potential future addition" once folks remembered WebGPU is a shipped API now.

Ideally we can skip the chromestatus features because it takes some time to fill the form and engineers are often puzzled by what they should fill (I have been, multiple times), but if it drives other tooling then we can make an how-to specifically for the WebGPU team on how to do this for the "minor features". What is driven by the I2S email?

As Chris said, the Chromestatus entries drive an increasing number of things, such as all release announcement kinda things (i.e. beta blog posts, enterprise release notes, and other comms) are driven exclusively by what's in Chromestatus. Going forward, more external comms etc will be driven by what Chromium engineers do by the data in Chromestatus, so skipping creating the feature entries really isn't an option if we're changing things that are detectable by web developers. The I2S emails themselves primarily drive the public discussion on whether API owners are in agreement to ship a feature or not, though the API owner approvals, and other approvals as well, are driven by the Chromestatus tool.

I would love to hear any feedback you or your team have around making the creation of the feature entries easier. Please let me know, or file issues at https://github.com/GoogleChrome/chromium-dashboard/issues/new/choose.

Cheers,

Johnny

- jstenback (he/him)

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAGdfWNMfWLEsT94HQMbEA7CmMxjMe6coF9_Lh%2BGVAjoQjRTWag%40mail.gmail.com.

[Ken Russell]

Hi Johnny,

On Tue, Oct 10, 2023 at 12:53 PM Johnny Stenback <jste...@google.com> wrote:

Hey Corentin,

On Tue, Oct 10, 2023 at 7:49 AM 'Corentin Wallez' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

Hey all,

Thank you all for being potentially open to this idea, and it seems very reasonable! Thank you also for detailing the concern about "bikeshed after shipping", it makes a lot of sense and we definitely want to avoid this issue. I can work with Firefox and WebKit to have some form of "stage" mechanism as well. Or at least agreement that things landing in specs after approval in a meeting with all parties involved means that after there are shipping implementations, they shouldn't be broken. If we had this, then the WebGPU folks would break down interactions with blink-dev as such:

• A grouped PSA for minor features where completely confident there won't be any risk. Examples are:
• Addition of trivial enums like sent earlier on blink-dev. 
• Non-breaking changes that make more WebGPU calls allowed, for example this PR after approval from other vendors.
• Similarly minor, non-breaking changes to WGSL.
• Intent to implement and ship, with implicit signals (if Firefox and WebKit agree to this in the W3C group) for medium size features, for example:
• WebGPU shader-f16 (though on this one we have signals, which is important since we didn't agree to a "stage" mechanism yet).
• Dual-source-blending once the names bikeshed in the group, and landed in the spec.
• Regular process for large features, or any feature that might carry an interop/bikeshed risk (these will likely to the TAG as well). For example WebGPU compatibility mode.

In the past there has been a single breaking change, and it was bundled in the release that turned WebGPU from an OT into a shipped API: Remove WebGPU limit maxFragmentCombinedOutputResources. And recently in the group there were discussions about potentially changing the semantic of a few things which quickly turned into "maybe potential future addition" once folks remembered WebGPU is a shipped API now.

Ideally we can skip the chromestatus features because it takes some time to fill the form and engineers are often puzzled by what they should fill (I have been, multiple times), but if it drives other tooling then we can make an how-to specifically for the WebGPU team on how to do this for the "minor features". What is driven by the I2S email?

As Chris said, the Chromestatus entries drive an increasing number of things, such as all release announcement kinda things (i.e. beta blog posts, enterprise release notes, and other comms) are driven exclusively by what's in Chromestatus. Going forward, more external comms etc will be driven by what Chromium engineers do by the data in Chromestatus, so skipping creating the feature entries really isn't an option if we're changing things that are detectable by web developers. The I2S emails themselves primarily drive the public discussion on whether API owners are in agreement to ship a feature or not, though the API owner approvals, and other approvals as well, are driven by the Chromestatus tool.

I would love to hear any feedback you or your team have around making the creation of the feature entries easier. Please let me know, or file issues at https://github.com/GoogleChrome/chromium-dashboard/issues/new/choose.

Would it be possible for our team to use the Chromestatus tool in a lightweight manner for most of these changes? In my opinion, these minor and even medium-sized features fall under the Chromestatus category of "Web developer-facing change to existing code". There are no security/privacy implications, and they're written up in the living spec ahead of time, with agreement by all browser vendors.

In the WebGL domain, this category was used when exposing the WebGLContextEvent prototype to web workers, and it worked well with no concerns by the API owners. Even the signals weren't necessary to gather because the change was already in the living spec.

If our team can create a brief ChromeStatus entry like "Add new foobar texture format to WebGPU" with reasonable description, etc., and then directly go to the "Prepare to ship" phase as was done for the WebGLContextEvent change, just garnering LGTMs from the API owners, I think that wouldn't add too much overhead. What do you all think?

-Ken

[Chris Wilson]

We are currently refactoring the description around "Web developer-facing change to existing code", because it's being misread.  That feature type is for features that don't change API shape, or add behavior - it's supposed to be essentially for PSAs for code refactoring, etc.  (Jason and I had a discussion about this yesterday.). PSAs do not require API Owner approval; except we're working to improve the path so that if there is high risk to the change, 

The type of changes you describe are "Existing feature implementation" (also slightly mis-named, which Jason is working on improving) - that is, there is already an agreed-upon specification, and an implementation of that feature is being added (or significantly changed in observable behavior).  There is a lot less focus on the incubation phase and spec development in this case, and we should be streamlining it for groups (like JS, WASM, CSS, and [it sounds like] WebGPU) that have clear signals of implementer support in their group/specification process already (e.g. the Stages in TC39 mean we don't need to separately collect signals for a stage 3+ feature implementation).

In places where Chromestatus is seeming overly heavyweight for engineers to fill out - and I am sure this is true - we really do want to work to streamline those paths, while ensuring we're tracking and getting appropriate approvals at the same time.  It would probably be a good idea for Jason and I to walk through some feature examples with you, and see how the path can be streamlined.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAMYvS2eQNu99ddOCu%2BFA_eiBnH07Q9oemTRQiP7BXm_-1pYkZw%40mail.gmail.com.

[Ken Russell]

Thanks, would appreciate the opportunity to work with you, Jason and Corentin on these feature examples. All of the WebGPU features we've been discussing - those contained entirely within the API and not involving interoperability with other web APIs - have zero privacy or security implications, and from our team's standpoint it's crucial to allow skipping of those reviews. Many of these, like adding new texture formats, are barely even web-observable; they don't show up in any ECMAScript objects, and it's only possible to notice the behavioral change by actually trying to create a texture with the new type. Due to the many small improvements ongoing in WebGPU, for Chromestatus and the Blink intent processes to work for our team, we really do need them streamlined like in the WebGLContextEvent-on-workers example I provided.

Thanks,

-Ken