Review request for 'Intent to Ship: WebGPU f16 support'

[Ryan Harrison]

This is my first time going through the Blink Intent to Ship process, and would like a review of my I2S email before sending it out formally.

Draft Body:

Contact emails

rhar...@chromium.org

Explainer

None

Specification

https://www.w3.org/TR/webgpu/#shader-f16

Summary

Allows for the use of the half-precision floating-point type f16 in WebGPU shaders (WGSL). Developers can use the 'shader-f16' feature from the WebGPU spec and the 'f16' extension from the WGSL spec to access 16-bit floating point variables and APIs in their shaders.

Blink component

Internals>GPU>Dawn

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: Positive Mozilla is an active member of the WebGPU/WGSL WG where the related spec changes were discussed and approved.

WebKit: Positive Apple is an active member of the WebGPU/WGSL WG where the related spec changes were discussed and approved.

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None at the moment, WebGPU currently does not ship on Android WebView. Parallel work is occuring to launch WebGPU on Android.

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No

All platforms will eventually have support. Will immediately be available on Mac and Chrome OS, since those are platforms already support WebGPU. Windows support depends on internal changes to use DXC, which are in progress, so f16 will become availabe once that is finished. Linux and Android are planned to have WebGPU support in the future, so feature will become available when WebGPU does.

Is this feature fully tested by web-platform-tests?

No

WebGPU/WGSL have a conformance test suite (https://github.com/gpuweb/cts) that is regularly pulled into Chromium and part of the testing of Dawn/Tint in Chromium. Test coverage for execution of f16 operations has been implemented, https://github.com/gpuweb/cts/issues/1248. Additional testing is in development.

Flag name on chrome://flags

None

Finch feature name

WebGPUExposeShader16

Requires code in //chrome?

False

Availability expectation

Feature is available only in Chromium browsers for the near future, on the order of months. Other browsers intend to ship WebGPU and f16 support, but don't have specified timelines.

Adoption expectation

Feature is used by specific partner(s) to provide functionality within 12 months of launch in Chrome.

Adoption plan

Multiple partners are actively developing products/features that will use f16 in WebGPU.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No

Estimated milestones

Shipping on desktop

120

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None, f16 has been landed in the WebGPU and WGSL specs https://github.com/gpuweb/gpuweb/pull/2696 (There is some discussion about whether or not explicit enabling of extensions should be required. Currently it is, so If this changes existing shaders would be fine because the desire is to make enabling optional, not removing the mechanism entirely).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5180552617656320

This intent message was generated by Chrome Platform Status.

[Reilly Grant]

Do you have any working mode documentation you can point to to back up the assertion that "Apple and Mozilla are in the WG where this was discussed so they approve"? Links to WebKit or Gecko bugs for implementing the feature would be helpful.

Developer signals should also be filled in. Why are we shipping this if no developer is interested in it? 

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

--
You received this message because you are subscribed to the Google Groups "spec-mentors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spec-mentors...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/spec-mentors/CAM4DYDYKqZ5Sa29hmbdh58EtyBpcb4sJxHj3%3D4UNODHNtV32ig%40mail.gmail.com.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Ryan Harrison]

+cc: cwallez, since he is the lead for WebGPU and probably can answer things more authoritatively (I meant to include him on the original email)

On Wed, 4 Oct 2023 at 13:31, Reilly Grant <rei...@chromium.org> wrote:

Do you have any working mode documentation you can point to to back up the assertion that "Apple and Mozilla are in the WG where this was discussed so they approve"? Links to WebKit or Gecko bugs for implementing the feature would be helpful.

There is WebKit bug for f16 support, https://bugs.webkit.org/show_bug.cgi?id=254668

Doesn't look like there is Mozilla/Gecko bug for f16 support at the moment. Looking at their bug tracker, it looks focused on implementing v1 of WebGPU and f16 is a  post-v1 feature.
I don't have explicit intent to implement the feature, but Kelsey Gilbert from Mozilla chairs the WGSL spec meetings, so is definitely aware of the feature and I don't recall her objecting to it. Kelsey and Jim from Mozilla were at the meeting where f16 was approved for merging into the spec, https://github.com/gpuweb/gpuweb/wiki/wgsl-2022-04-12-minutes#fp16-extension-against-spec-2696 (Representatives from Apple were also at that meeting)
Would this be considered sufficient evidence?

 

Developer signals should also be filled in. Why are we shipping this if no developer is interested in it? 

There are definitely internal and external partners that are actively interested in using f16, I am not sure the best way to capture that here, since I am not sure how much of that is currently publicly disclosable. I would probably have to loop in someone more involved in the product side for the specific details.

For things I know that are public:
- Intel has been heavily involved in spec'ing the feature and implementing the feature in Dawn/Chrome, so it isn't something being solely driven by Googlers.
From the original discussion about adding f16, https://github.com/gpuweb/gpuweb/issues/658:
- There is a substantial performance benefit shown in demos/tests, ~25% if ALU bound, and upto 50% if memory bound.

- The underlying platforms that WebGPU uses (Metal/Vulkan/Direct3D) implement f16 support

- TF.js was cited as an external project actively investigating using it, (it is definitely used in their WebGL implementation)

[Panos Astithas]

Note that Khronos-hosted specs are exempted from the requirement for browser signals per bit.ly/blink-signals.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/spec-mentors/CAM4DYDZBGEMYwXuyO3cK4mGDtambKvyDjc1ReKYmpanYZd8Rww%40mail.gmail.com.

[Ryan Harrison]

WebGPU is W3C, not Khronos. WebGL was Khronos.
I think Corentin was discussing getting a similar exemption recently.

[Reilly Grant]

On Wed, Oct 4, 2023 at 11:08 AM Ryan Harrison <rhar...@chromium.org> wrote:

+cc: cwallez, since he is the lead for WebGPU and probably can answer things more authoritatively (I meant to include him on the original email)

On Wed, 4 Oct 2023 at 13:31, Reilly Grant <rei...@chromium.org> wrote:

Do you have any working mode documentation you can point to to back up the assertion that "Apple and Mozilla are in the WG where this was discussed so they approve"? Links to WebKit or Gecko bugs for implementing the feature would be helpful.

There is WebKit bug for f16 support, https://bugs.webkit.org/show_bug.cgi?id=254668

Doesn't look like there is Mozilla/Gecko bug for f16 support at the moment. Looking at their bug tracker, it looks focused on implementing v1 of WebGPU and f16 is a  post-v1 feature.
I don't have explicit intent to implement the feature, but Kelsey Gilbert from Mozilla chairs the WGSL spec meetings, so is definitely aware of the feature and I don't recall her objecting to it. Kelsey and Jim from Mozilla were at the meeting where f16 was approved for merging into the spec, https://github.com/gpuweb/gpuweb/wiki/wgsl-2022-04-12-minutes#fp16-extension-against-spec-2696 (Representatives from Apple were also at that meeting)
Would this be considered sufficient evidence?

Typically attendance at a meeting where a change was discussed is not considered to be a positive signal for that change. Unless the working group process requires implementation commitments before a change is landed there isn't any reason to expect that other implementers have reviewed and intend to implement the feature. The minutes say that David and Alan approved but guessing from the attendee list both of them are Googlers.

I assume the reason why Khronos specifications were exempted from the signals requirement is that their process requires consensus before adopting changes while W3C working groups have a bad habit of being a bit loose.

 

Developer signals should also be filled in. Why are we shipping this if no developer is interested in it? 

There are definitely internal and external partners that are actively interested in using f16, I am not sure the best way to capture that here, since I am not sure how much of that is currently publicly disclosable. I would probably have to loop in someone more involved in the product side for the specific details.

For things I know that are public:
- Intel has been heavily involved in spec'ing the feature and implementing the feature in Dawn/Chrome, so it isn't something being solely driven by Googlers.
From the original discussion about adding f16, https://github.com/gpuweb/gpuweb/issues/658:

This ONNX issue that mentions that one would be a good signal of developer interest: https://github.com/microsoft/onnxruntime/issues/9758 

 

- There is a substantial performance benefit shown in demos/tests, ~25% if ALU bound, and upto 50% if memory bound.

Linking to public demo benchmark results would be a good signal.

 

- The underlying platforms that WebGPU uses (Metal/Vulkan/Direct3D) implement f16 support

- TF.js was cited as an external project actively investigating using it, (it is definitely used in their WebGL implementation)

Linking to that citation or the actual backend code where TF.js is using this would be a good signal.

[Corentin Wallez]

On Thu, Oct 5, 2023 at 1:01 AM Reilly Grant <rei...@chromium.org> wrote:

On Wed, Oct 4, 2023 at 11:08 AM Ryan Harrison <rhar...@chromium.org> wrote:

+cc: cwallez, since he is the lead for WebGPU and probably can answer things more authoritatively (I meant to include him on the original email)

On Wed, 4 Oct 2023 at 13:31, Reilly Grant <rei...@chromium.org> wrote:

Do you have any working mode documentation you can point to to back up the assertion that "Apple and Mozilla are in the WG where this was discussed so they approve"? Links to WebKit or Gecko bugs for implementing the feature would be helpful.

There is WebKit bug for f16 support, https://bugs.webkit.org/show_bug.cgi?id=254668

Doesn't look like there is Mozilla/Gecko bug for f16 support at the moment. Looking at their bug tracker, it looks focused on implementing v1 of WebGPU and f16 is a  post-v1 feature.
I don't have explicit intent to implement the feature, but Kelsey Gilbert from Mozilla chairs the WGSL spec meetings, so is definitely aware of the feature and I don't recall her objecting to it. Kelsey and Jim from Mozilla were at the meeting where f16 was approved for merging into the spec, https://github.com/gpuweb/gpuweb/wiki/wgsl-2022-04-12-minutes#fp16-extension-against-spec-2696 (Representatives from Apple were also at that meeting)
Would this be considered sufficient evidence?

Typically attendance at a meeting where a change was discussed is not considered to be a positive signal for that change. Unless the working group process requires implementation commitments before a change is landed there isn't any reason to expect that other implementers have reviewed and intend to implement the feature. The minutes say that David and Alan approved but guessing from the attendee list both of them are Googlers.

I assume the reason why Khronos specifications were exempted from the signals requirement is that their process requires consensus before adopting changes while W3C working groups have a bad habit of being a bit loose.

 

The WebGPU group keeps the same habit from Khronos where stuff doesn't land in the spec until all participants are ok with it. See below the draft of an email I'm planning to send to Blink API owners that asks for a carve-out and gives more context. Note that Mozilla doesn't have an issue to track shader-f16 because their WebGPU implementation already supports it.

The draft email in question.

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.

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 coming soon, 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.

Cheers,

Corentin 

[Reilly Grant]

I'm not a Blink API owner but this all seems reasonable to me. The only thing I'd like to see is a pointer to where the WebGPU's consensus requirements are documented.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

[Ryan Harrison]

The charter states that decisions are by consensus unless an explicit vote is held, https://www.w3.org/2022/11/gpuweb-charter.html, section 8. Is that sufficient?

[Reilly Grant]

That is the default decision policy that all Working Groups use. What I would like to see to be more confident that changes are being made with cross-vendor consensus is something like the PR template you see for in WebApps WG repos which explicitly asks authors to confirm that there's implementation commitment from everybody: https://github.com/w3c/manifest/blob/main/.github/PULL_REQUEST_TEMPLATE.md

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome