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 first >>> 139 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.
