Intent to Deprecate and Remove: Remove non-standard GPUAdapter requestAdapterInfo() method

[François Beaufort‏]

Contact emails

fbea...@google.com

Explainer

None

Specification

https://gpuweb.github.io/gpuweb/#dom-gpuadapter-info

Summary

The WebGPU WG decided it was impractical for requestAdapterInfo() to trigger a permission prompt so they’ve removed that option and replaced it with the GPUAdapter info attribute so that web developers can get the same GPUAdapterInfo value synchronously this time. See the previous intent to ship at https://groups.google.com/a/chromium.org/g/blink-dev/c/eZqMmX7q_bA/m/euMLVMpxAgAJ

Blink component

Blink>WebGPU

Motivation

The requestAdapterInfo() asynchronous method in WebGPU is redundant because developers can already get GPUAdapterInfo synchronously using the GPUAdapter info attribute. Hence, it should be removed.

A search for the string "requestAdapterInfo" in HTTPArchive yielded no results.

According to https://chromestatus.com/metrics/feature/timeline/popularity/4977, the requestAdapterInfo() method accounted for approximately 0.41% of page loads in September 2024.

Chrome UKMs helped us in identifying the most popular websites using the WebGPU requestAdapterInfo() method: - Twitch: The team has been contacted and has indicated that they will update their code. - Dynatrace: Used by the vast majority of those websites for analytics, they have been made aware of this deprecation.

Initial public proposal

None

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

When WebGPU eventually launches in Safari and Firefox, websites will be able to get GPUAdapterInfo values exclusively through the standardized GPUAdapter info attribute. We anticipate Safari and Firefox will soon support WebGPU, but won't include this non-standard method. Therefore, the sooner Chromium implements the Deprecate and Remove process, the less likely it is that content will work in Chromium but not in other browsers. In Chromium-based browsers, as the requestAdapterInfo() asynchronous method returned a promise, websites that followed best practices were already catching rejected promises. Web developers have been made aware of this change in July 2024 at https://developer.chrome.com/blog/new-in-webgpu-127?hl=en#gpuadapter_info_attribute. They can use the following one-line code during the transition period: const info = adapter.info || await adapter.requestAdapterInfo();

Gecko: No signal

WebKit: No signal

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

Debuggability

None

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

No

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5140787340509184?gate=5110989125844992

This intent message was generated by Chrome Platform Status.

[Mike Taylor‏]

I know that WebKit !== Safari, but I do see they have requestAdapterInfo today. Do we have any sense of what their plans are there (maybe a standards position could clarify that)?

Gecko: No signal

WebKit: No signal

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

Debuggability

None

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

No

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5140787340509184?gate=5110989125844992

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5KohE-NU%2B0bAsWzgaNLUCPGCqBr%2BH3jpoY58yGK-frwOg%40mail.gmail.com.

[François Beaufort‏]

As you can see in https://github.com/gpuweb/gpuweb/pull/4662#issuecomment-2141279713, they re-added temporarily requestAdapterInfo() at the time to avoid breaking websites that didn't make the move yet.
FYI, I've updated Apache TVM used by WebLLM to use adapter.info in apache/tvm#17051.

[Mike Taylor‏]

Cool - does that mean WebKit is willing to remove it now (or shortly after we do)?

[François Beaufort‏]

I believe they do but I'll let them respond to that: https://github.com/gpuweb/gpuweb/pull/4662#issuecomment-2338474559 

[François Beaufort‏]

https://github.com/gpuweb/gpuweb/pull/4662#issuecomment-2338982367 indicates they have just removed it in WebKit as expected.

[Yoav Weiss (@Shopify)‏]

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Yoav Weiss (@Shopify)‏]

Wait, I was a bit quick on that LGTM (excited about the removal in WebKit, I guess).

You're saying that our latest data is that this API is used in 0.41% of requests. What happens to that usage (which seems concentrated to a few 3P scripts) when the API is removed? What does breakage in practice look like?

[François Beaufort‏]

I've checked with a Chromium build that removes the requestAdapterInfo() method and the websites I've tried are not broken.
The content of the string sent for analytics is simply different but the POST request still happens properly.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Yoav Weiss (@Shopify)‏]

OK, LGTM1 then :D

[Mike Taylor‏]

LGTM2 % requesting review bits for Enterprise, Debuggability, and Testing.

Sites could fail if they're still calling this, but I trust the team to handle outreach (as they've already done) and react accordingly.

[Daniel Bratell‏]

It's a bit scary, but given the analysis, the risk seems contained. You listed None as Finch flag though. I think it's policy, and prudent, to make changes like this protected by a flag so that it can be undone if we're wrong.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2Bor7cp5TfwDyo2F1TkwMyyDacvnL9jFv%2Bsq4xpZhy5cg%40mail.gmail.com.

[François Beaufort‏]

Good point Daniel! I'll go update the chrome status entry.
Here's how we'll proceed:
1. We'll deprecate the method with `DeprecateAs` in the IDL file
2. Then we'll add a blink runtime feature off by default that hides the method with `RuntimeEnabled` to remove it
3. And finally we can remove it completely in the IDL file.

[Alex Russell‏]

LGTM3

OK, LGTM1 then :D

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5KohE-NU%2B0bAsWzgaNLUCPGCqBr%2BH3jpoY58yGK-frwOg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Daniel Bratell‏]

Bonus LGTM4

/Daniel