WebGPU Reaches Further: Compatibility Mode Lands on OpenGL ES 3.1
Source: chrome-devblog
Chrome 146 shipped two WebGPU updates that, on the surface, sound incremental but are actually kind of a big deal depending on what hardware you care about.
Compatibility Mode on OpenGL ES 3.1
WebGPU’s compatibility mode is a lower-requirements tier designed to run on hardware that can’t support Vulkan, Metal, or D3D12. Chrome 146 extends that to OpenGL ES 3.1, which is a significant expansion in practice.
OpenGL ES 3.1 is everywhere. Mid-range Android devices, embedded systems, older GPUs that never got Vulkan drivers — they all speak GLES 3.1. Previously, if your user’s device couldn’t back WebGPU with a modern graphics API, they got nothing. Now they get compatibility mode.
This matters most if you’re targeting the web broadly rather than just high-end desktop. Mobile web GPU workloads — think ML inference in the browser, WebGL-replacement rendering, image processing pipelines — have always had a deployment problem. You’d write WebGPU code, it’d work great on your M-series Mac, and then fall back to nothing on a budget Android phone from two years ago. Compatibility mode doesn’t give you everything, but it gives you something.
The tradeoff is real: compatibility mode has restrictions. You can’t rely on the full WebGPU feature set. But for compute-heavy workloads that don’t need bleeding-edge GPU features, this is a reasonable path to broader reach.
Transient Attachments
The second addition is transient attachments in render passes. This is a performance feature aimed squarely at tile-based GPUs, which dominate mobile.
The idea: if a render pass attachment (like a depth buffer or intermediate color target) is only needed within that pass and never read back to main memory, you can declare it transient. The GPU driver knows it never has to write that data out — it can keep everything in the fast on-chip tile memory for the duration of the pass.
On traditional desktop discrete GPUs this doesn’t mean much. But on tile-based architectures — basically all mobile GPUs — the bandwidth savings are real. Main memory reads and writes are expensive. Keeping intermediate render targets in tile memory is one of the core optimizations those architectures are designed around, and WebGPU now has a first-class way to express that intent.
Why This Combination Makes Sense
These two features together tell a coherent story: the Chrome team is pushing WebGPU toward mobile viability. Compatibility mode gets you running on more devices; transient attachments let you run efficiently on the GPU architectures those devices use.
WebGPU has always had a “great on desktop” reputation. Getting it to be genuinely useful on the 6-billion-device Android ecosystem is a harder problem. These aren’t the final pieces, but they’re clearly part of that push.
If you’re building anything GPU-heavy for the browser — game engines, ML inference, visual compute — it’s worth checking what assumptions you’re making about your target hardware and whether compatibility mode changes your deployment story.