WebGPU Goes Wider: OpenGL ES 3.1 Compatibility Mode and Transient Attachments in Chrome 146

Two quiet but meaningful additions landed in Chrome 146’s WebGPU update: compatibility mode now works on OpenGL ES 3.1, and transient attachments are in. Neither is flashy, but together they represent a real broadening of what WebGPU can run on and how efficiently it can run.

Compatibility Mode on OpenGL ES 3.1

WebGPU’s native targets — Vulkan, Metal, D3D12 — are available on most modern hardware, but Android’s device fragmentation is notorious. A meaningful slice of active Android devices never got Vulkan, or ship with Vulkan drivers that are barely functional. OpenGL ES 3.1, on the other hand, has been around since 2014 and has solid driver coverage across budget and mid-range devices.

WebGPU’s compatibility mode was introduced precisely to handle this situation: it sacrifices a handful of features (like some texture view reinterpretation behaviors) in exchange for running on a wider backend surface. Extending that to GLES 3.1 means developers who opt into compatibility mode can now reach a substantially larger pool of Android devices without shipping a completely different rendering path.

The tradeoff is real — you’re constrained by what GLES 3.1 can express — but for many workloads (2D rendering, lightweight 3D, compute) you won’t notice the difference. The option being there at all is what matters.

Transient Attachments

This one is the more technically interesting addition. A transient attachment is a render target that only needs to exist for the duration of a single render pass. Think of a G-buffer depth texture used for deferred lighting, or an MSAA resolve target that you only need during the pass before discarding.

On desktop GPUs with large amounts of VRAM and high memory bandwidth, storing these attachments in main memory is fine. On tile-based deferred renderers (TBDRs) — the dominant architecture in mobile GPUs from Apple, Qualcomm, ARM, and Imagination — it’s genuinely wasteful. TBDRs work by rasterizing geometry into small screen tiles entirely in fast on-chip memory before flushing results to main memory. If an attachment is only used within a pass and then discarded, there’s no reason it ever needs to touch main memory at all.

Transient attachments let you declare that intent explicitly:

const texture = device.createTexture({
  usage: GPUTextureUsage.RENDER_ATTACHMENT,
  transientAttachment: true,
  // ...
});

With this flag set, the browser and driver can keep the attachment entirely in tile memory for its lifetime. On mobile hardware that’s a real bandwidth win — less memory traffic means lower power draw and better frame times, which matters a lot on devices that are simultaneously thermally constrained and running on battery.

Why This Pair of Features Makes Sense Together

Compatibility mode reaching GLES 3.1 expands WebGPU to more mobile devices. Transient attachments let you write more efficient rendering code on those same devices. They’re not related at the spec level, but landing them together is convenient: if you’re building a WebGPU renderer that needs to run well on mid-range Android, you now have both broader coverage and a concrete performance tool to use on the hardware you’re targeting.

WebGPU’s trajectory is increasingly about reach and efficiency alongside raw capability. These two additions fit that pattern well.