LGTM1
On Thu, Jan 22, 2026 at 10:57 PM Ken Russell <[email protected]> wrote:
Hi Alex and Blink API OWNERS,
Can we continue moving forward this discussion? Google's WebGPU
team is working with a few partners to ensure their products work
in WebGPU Compatibility mode to increase their reach, and we're
working on gathering their feedback which can be shared publicly.
But please be assured that this work is already ongoing.
WebGPU's Compatibility Mode allows developers to opt-in to a
slightly reduced API surface and dramatically expand the reach of
their applications to older Android, Windows and ChromeOS devices.
All of the major browser vendors have been involved in the
development of Compatibility Mode for years, and all are in
agreement that its specification is ready, and that it's OK to
ship implementations. (Compatibility Mode wouldn't have landed in
the WebGPU specification if there hadn't been consensus among all
the vendors.)
Thanks,
-Ken
On Wed, Jan 14, 2026 at 1:26 PM Kai Ninomiya
<[email protected]> wrote:
On Wed, Jan 14, 2026 at 8:05 AM Alex Russell
<[email protected]> wrote:
It's a little odd that there's no developer feedback here.
Fair point. The main impact is just "you can ship on more
devices", which developers certainly want, but of course
WebGPU must still be usable with the restrictions. We /do/
have positive feedback on that, which we will follow up with
shortly.
Is it correct that we're shipping first?
Yes, but more than that, we don't expect all browsers to ship
it ever. Compatibility mode was specifically designed to
interoperate as well as possible with other browsers that
/never/ implement it (Safari), and Safari+Firefox have
reviewed the API thoroughly in the WG and approved it with
this in mind. It is expected to be a positive force for WebGPU
adoption overall as it reduces the need for applications to
continue to support WebGL.
Firefox /is/ considering implementing Compatibility Mode, but
of course it competes with their priorities for other WebGPU
features. (Compatibility Mode is mostly for old and
very-low-spec/below-baseline Android devices, which are
relatively more critical for Chromium as a core Android system
component.)
And is there a list of features that will not be available
in this mode?
The detailed proposal doc enumerates them:
https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md
That should be complete, but of course the final details are
in the spec itself.
Does it unlock software rendering?
No, only hardware rendering on more devices (that are less
capable).
These days, software renderers (WARP, Lavapipe) are among the
/more/ capable implementations of graphics APIs, since they
have no hardware dependency and can implement anything with
sufficient effort (which has been happening).
-Kai(he/they)
(Google)
Thanks,
Alex
On Wednesday, January 14, 2026 at 6:22:11 AM UTC-8 Stephen
White wrote:
Sure! The above proposal was converted into spec text
on a feature branch. This
<https://github.com/gpuweb/gpuweb/commit/6eae31ebb74b4877d91ddce47865ba89bf1ae1a5>
is
the merge commit that brought those changes into the
main spec. The changes are not isolated to a single
section, but each restriction appears in a cyan box
labelled "Compatibility Mode", easiest to find by
searching for "core-features-and-limits".
These are the (largely minor) followup changes that
landed after that merge:
* Disallow cube-array in createTexture
<https://github.com/gpuweb/gpuweb/commit/f34e4301de148b82936737bf7312c0a496b6e7e2>
* Fix maxStorageTexturesIn*Stage defaults
<https://github.com/gpuweb/gpuweb/commit/78dfad2eb1c8dcbd00430562e147eb3a052a5e3e>
* [editorial] Tweak requestAdapter step ordering,
feature level definitions (again)
<https://github.com/gpuweb/gpuweb/commit/b984d18e327a5691dfdf7cc2b8746972552e2c54>
Stephen
On Wed, Jan 14, 2026 at 8:48 AM Yoav Weiss (@Shopify)
<[email protected]> wrote:
On Tuesday, January 13, 2026 at 9:16:24 PM UTC+1
Chromestatus wrote:
*Contact emails*
[email protected], [email protected]
*Explainer*
https://github.com/explainers-by-googlers/webgpu-compatibility-mode/blob/main/README.md
<https://github.com/explainers-by-googlers/webgpu-compatibility-mode/blob/main/README.md>
*Specification*
https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md
<https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md>
Can you point to a PR or a spec section that
includes the change?
*Summary*
Adds an opt-in, lightly restricted subset of
the WebGPU API capable of running older
graphics APIs such as OpenGL and Direct3D11.
By opting into this mode and obeying its
constraints, developers can extend the reach
of their WebGPU applications to many older
devices that do not have the modern, explicit
graphics APIs that core WebGPU requires. For
simple applications, the only required change
is to specify the "compatibility" featureLevel
when calling requestAdapter. For more advanced
applications, some modifications may be
necessary to accommodate the mode's
restrictions. Since Compatibility mode is a
subset, the resulting applications are also
valid WebGPU Core applications and will run
even on user agents that do not support
Compatibility mode.
*Blink component*
Blink>WebGPU
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebGPU%22>
*Web Feature ID*
webgpu <https://webstatus.dev/features/webgpu>
*Motivation*
WebGPU is a good match for modern graphics
APIs such as Vulkan, Metal and Direct3D 12.
However, there are a large number of devices
which do not yet support those APIs. In
particular, on Chrome on Windows, 31% of
Chrome users do not have Direct3D FL 11.1 or
higher. On Android, 23% of Android users do
not have Vulkan 1.1, including 15% who do not
have Vulkan at all
(https://developer.android.com/about/dashboards
<https://developer.android.com/about/dashboards>).
On ChromeOS, Vulkan penetration is still quite
low, while OpenGL ES 3.1 is ubiquitous.
Developers are thus forced to write multiple
implementations (e.g., WebGPU and WebGL) for
maximum reach, to accept the reduced reach
that core WebGPU currently provides, or to
write only for WebGL and forgo the advanced
features of WebGPU, such as GPU compute. By
opting in to Compatibility Mode, developers
can target a wider reach of devices with a
single implementation.
*Initial public proposal*
https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md
<https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md>
*TAG review*
https://github.com/w3ctag/design-reviews/issues/1063
<https://github.com/w3ctag/design-reviews/issues/1063>
*TAG review status*
Issues addressed
*Origin Trial Name*
WebGPU Compatibility Mode
*Chromium Trial Name*
WebGPUCompatibilityMode
*Origin Trial documentation link*
https://github.com/explainers-by-googlers/webgpu-compatibility-mode/blob/main/README.md
<https://github.com/explainers-by-googlers/webgpu-compatibility-mode/blob/main/README.md>
*WebFeature UseCounter name*
kWebGPUFeatureLevelCompatibility
*Risks*
*Interoperability and Compatibility*
This feature has been approved in W3C GPU for
the Web WG meetings including participants
from Safari and Firefox.
/Gecko/: Positive Although there is not
currently an entry for Compatibility Mode in
the standards positions repos, WebGPU
Compatibility Mode was discussed and approved
by Google, Apple and Mozilla in the GPU for
the Web Working Group, and has the same
support as WebGPU Core. Each of the commits to
the compatibility-mode propsal above was
approved by a working group member from each
of those three organizations, and any
disagreements were resolved prior to landing
in Working Group meetings.
/WebKit/: Positive Although there is not
currently an entry for Compatibility Mode in
the standards positions repos, WebGPU
Compatibility Mode was discussed and approved
by Google, Apple and Mozilla in the GPU for
the Web Working Group, and has the same
support as WebGPU Core. Each of the commits to
the compatibility-mode propsal above was
approved by a working group member from each
of those three organizations, and any
disagreements were resolved prior to landing
in Working Group meetings.
/Web developers/: No signals
/Other signals/:
*Security*
Being a lightly-restricted subset,
Compatibility Mode does not introduce any
accessibility, security, or privacy issues
over and above those introduced by core
WebGPU. For this reason, the security review
submitted for WebGPU also applies to
Compatibility Mode.
*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?
Low; does not remove or alter existing APIs.
Provides a lightly-restricted subset of the
WebGPU API to older devices which are not
capable of the core WebGPU API In case of
emergency, there are two independent
killswitches: - kWebGPUAndroidOpenGLES
controls the Dawn OpenGLES backend on Android
in the GPU process - RuntimeEnabledFeature
kWebGPUCompatibilityMode controls the JS API
in the renderer process
*Debuggability*
/No information provided/
*Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux,
ChromeOS, Android, and Android WebView)?*
No
All platforms will eventually have support.
Will immediately be available on Android,
Android WebView, ChromeOS, Mac, and Windows,
where hardware support is available. Linux is
planned to have WebGPU support in the future,
so this feature will become available when
WebGPU does.
*Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
Yes
All Compatibility Mode restrictions are
exercised by the "compatibility" option to the
WebGPU CTS. E.g.,
https://gpuweb.github.io/cts/standalone/?compatibility=1&q=webgpu:*
<https://gpuweb.github.io/cts/standalone/?compatibility=1&q=webgpu:*>
This subset is tested extensively on the Dawn
CI
(https://ci.chromium.org/p/chromium/g/chromium.dawn/console
<https://ci.chromium.org/p/chromium/g/chromium.dawn/console>)
under the "webgpu_cts_compat_tests" suite.
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. While the
CTS can be embedded in WPT, the WebGPU team
opted to keep it separate in Chromium testing
to use a customized harness for robustness and
performance.
*Flag name on about://flags*
/No information provided/
*Finch feature name*
WebGPUCompatibilityMode
*Rollout plan*
Will ship enabled for all users
*Requires code in //chrome?*
False
*Tracking bug*
https://crbug.com/442618060
*Availability expectation*
Mozilla is interested in this feature (and has
approved all of the spec changes) but has not
committed to implementing it yet. Apple has
approved all of the spec changes, but it is
not anticipated that this feature will ship in
Safari since all Apple devices on the market
can support the full Core WebGPU spec.
However, since it is designed as a subset,
Compatibility mode applications will work
unchanged in browsers that only support Core
(e.g., Safari).
*Adoption expectation*
Feature is used by specific partner(s) to
provide functionality within 12 months of
launch in Chrome.
*Adoption plan*
Adoption of Core WebGPU proceeds apace
(https://chromestatus.com/metrics/feature/timeline/popularity/4029
<https://chromestatus.com/metrics/feature/timeline/popularity/4029>),
and it is expected that developers will adopt
Compatibility Mode because it allows them to
extend the reach of their WebGPU content to a
larger audience.
*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?
On Android, this feature depends on the
OpenGLES 3.1 graphics API in order to provide
WebGPU capability to older devices. The
JavaScript API will be available on all
platforms, including desktop, but will not
require any new graphics APIs; it will simply
allow developers to test the Compatibility
Mode subset on all Chrome platforms.
*Estimated milestones*
Shipping on desktop146 Origin trial desktop
first139 Origin trial desktop last145 Shipping
on Android146 Origin trial Android first139
Origin trial Android last145 Shipping on
WebView146 Origin trial WebView first139
Origin trial WebView last145
*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).
All Compatibility Mode changes have landed in
the WebGPU core spec:
https://www.w3.org/TR/webgpu/; all known
issues have been addressed.
*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/6436406437871616?gate=6221450639572992
<https://chromestatus.com/feature/6436406437871616?gate=6221450639572992>
*Links to previous Intent discussions*
Intent to Experiment:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/683618d7.170a0220.2aa17e.17c5.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/683618d7.170a0220.2aa17e.17c5.GAE%40google.com>
This intent message was generated by Chrome
Platform Status <https://chromestatus.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
[email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2c05e366-fc6b-453d-a4a6-86f3c38076f9n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2c05e366-fc6b-453d-a4a6-86f3c38076f9n%40chromium.org?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANxMeyA-BCxEdBNLQuKa_3scbHL9P712vTYZQcR_g5%3DBYV%3DUJQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANxMeyA-BCxEdBNLQuKa_3scbHL9P712vTYZQcR_g5%3DBYV%3DUJQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BbpJQT6mu06s5vB3V-sWihe2RFtdaZbjFOP7qNzkwOZQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BbpJQT6mu06s5vB3V-sWihe2RFtdaZbjFOP7qNzkwOZQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
