Thanks for adding that feedback! LGTM3

On Fri, Jan 23, 2026 at 12:35 PM 'Stephen White' via blink-dev <
[email protected]> wrote:

> Hi Alex,
>
> I've added a statement from Unity to the "Web / Framework developer views
> notes". Unity is an important partner, so this carries some weight. We will
> add more if/when it comes in.
>
> Stephen
>
> On Wed, Jan 14, 2026 at 11:05 AM Alex Russell <[email protected]>
> wrote:
>
>> 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/CAPeKFTh6JnVoWujtuFteRnMPg3Qt8Fi%2B3J0bc5ea78hcVMDa9Q%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPeKFTh6JnVoWujtuFteRnMPg3Qt8Fi%2B3J0bc5ea78hcVMDa9Q%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/CAOMQ%2Bw82BKfEchxWR8NHFLQJxo0OGbSKf0kYoNGGR2wV9bEAhQ%40mail.gmail.com.

Reply via email to