It's a little odd that there's no developer feedback here. Is it correct 
that we're shipping first? And is there a list of features that will not be 
available in this mode? Does it unlock software rendering?

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/a2274f68-c8e6-4bdd-bb0d-9b498fbfe11en%40chromium.org.

Reply via email to