WebGPU Reaches Further: Compatibility Mode and Transient Attachments in Chrome 146
Source: chrome-devblog
Chrome 146 quietly shipped two WebGPU additions that are worth paying attention to, especially if you care about where GPU-accelerated web apps can actually run.
Compatibility Mode Lands on OpenGL ES 3.1
The bigger deal here is WebGPU compatibility mode support on OpenGL ES 3.1. To understand why that matters, a quick refresher: WebGPU’s compatibility mode is a restricted subset of the API designed to work on hardware and drivers that can’t support the full WebGPU feature set. The full API targets Vulkan, Metal, and D3D12. Compatibility mode extends that reach by layering on top of older APIs.
OpenGL ES 3.1 is everywhere. It’s the baseline for a huge chunk of Android devices, embedded systems, and anything running a mid-range mobile GPU from the past several years. Getting WebGPU’s compatibility mode running on top of it means compute shaders and modern GPU pipelines become accessible on hardware that would otherwise be locked out.
This is the same problem that plagued WebGL for years — broad API availability, but significant capability gaps on low-end and mobile devices. WebGPU is trying to thread the needle differently: a well-defined compatibility tier rather than a messy patchwork of extensions.
For anyone building compute-heavy apps in the browser — ML inference, image processing, physics sims — this substantially widens your addressable audience without requiring you to fall back to WebGL.
Transient Attachments: A Win for Tile-Based GPUs
The other addition is transient attachments. This one is more targeted but has real performance implications on mobile.
Most desktop GPUs are immediate-mode renderers — they process each draw call and write results to memory as they go. Mobile GPUs (and Apple Silicon, notably) are typically tile-based deferred renderers (TBDRs). They divide the framebuffer into tiles, process all geometry for a tile at once in fast on-chip memory, and only flush to main memory at the end.
Transient attachments are render pass attachments that are allocated in that tile memory and explicitly never need to be persisted to main memory. Think of a depth buffer or a G-buffer intermediate that you only need within a single render pass. Marking them as transient tells the driver: don’t bother writing this back to DRAM.
The result on TBDR hardware is meaningful: fewer memory bandwidth round-trips, lower power consumption, better performance. On desktop hardware the hint is mostly ignored gracefully, so it’s a safe optimization to reach for.
In WebGPU terms, you’d specify this via the usage flags on a texture, signaling that the attachment contents don’t need to survive past the render pass that writes them.
Why This Progression Matters
These two features together tell a coherent story. Compatibility mode on OpenGL ES 3.1 is about reach — getting WebGPU into more hands on more devices. Transient attachments are about depth — giving developers the tools to write GPU code that actually performs well on the hardware those users are running.
WebGPU is still young, but the spec and the implementations are maturing in the right direction. The compatibility mode story in particular is something I’ll be watching closely as more mobile browsers ship it. If you’re building anything GPU-intensive for the web, now is a good time to start thinking in terms of the compatibility baseline rather than assuming Vulkan-class hardware on every device.