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 >>>>> >>>>> *Specification* >>>>> 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). 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 >>>>> >>>>> *TAG review* >>>>> 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 >>>>> >>>>> *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:* >>>>> This subset is tested extensively on the Dawn CI ( >>>>> 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), 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 >>>>> >>>>> *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 >>>>> >>>>> >>>>> 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.
