Chrome rolling out WebGPU support for Linux

andsoitis1 pts0 comments

What's New in WebGPU (Chrome 144) | Blog | Chrome for Developers

Skip to main content

English

Deutsch

Español – América Latina

Français

Indonesia

Italiano

Nederlands

Polski

Português – Brasil

Tiếng Việt

Türkçe

Русский

עברית

العربيّة

فارسی

हिंदी

বাংলা

ภาษาไทย

中文 – 简体

中文 – 繁體

日本語

한국어

Sign in

Blog

Chrome for Developers

Blog

What's New in WebGPU (Chrome 144)

Stay organized with collections

Save and categorize content based on your preferences.

François Beaufort

GitHub

Published: January 7, 2026

WGSL subgroup_id extension

The WGSL language extension subgroup_id lets you use the following new built-in values in workgroups when the subgroups extension is enabled:

subgroup_id: Provides the ID of an invocation's subgroup within the current workgroup.

num_subgroups: Reports the number of subgroups present in the workgroup.

Previously, to index memory using subgroup invocation IDs, you had to reconstruct a subgroup ID (typically through atomic operations) to avoid overlapping memory accesses. You can now use subgroup_id to fill the other half of that equation. Because this functionality is not available on the D3D backend yet, it's emulated there. It should be safe to create an equivalence to local_invocation_index as subgroup_invocation_id + subgroup_size * subgroup_id. Note that there might be cases where subgroups are not full.

This language extension can be feature-detected using navigator.gpu.wgslLanguageFeatures. It's recommended to use a requires-directive to signal the potential for non-portability with requires subgroup_id; at the top of your WGSL shader code. See the following example and the intent to ship.

if (!navigator.gpu.wgslLanguageFeatures.has("subgroup_id")) {<br>throw new Error(`WGSL subgroup_id and num_subgroups built-in values are not available`);

const adapter = await navigator.gpu.requestAdapter();<br>if (!adapter.features.has("subgroups")) {<br>throw new Error("Subgroups support is not available");<br>const device = await adapter.requestDevice({ requiredFeatures: ["subgroups"] });

const shaderModule = device.createShaderModule({ code: `<br>enable subgroups;<br>requires subgroup_id;

@compute @workgroup_size(64, 1, 1)<br>fn main(@builtin(subgroup_id) subgroup_id : u32,<br>@builtin(num_subgroups) num_subgroups : u32) {<br>// TODO: Use subgroup_id and num_subgroups values.<br>}`,<br>});

WGSL uniform_buffer_standard_layout extension

The WGSL language extension uniform_buffer_standard_layout lets uniform buffers use the same memory layout constraints as storage buffers, which makes it easier to share data structures in both kinds of buffers. This means uniform buffers are no longer required to have 16-byte alignment on array elements, or to pad nested structure offsets to a multiple of 16 bytes.

This language extension can be feature-detected using navigator.gpu.wgslLanguageFeatures. It's recommended to use a requires-directive to signal the potential for non-portability with requires uniform_buffer_standard_layout; at the top of your WGSL shader code. See the following example and the intent to ship.

if (!navigator.gpu.wgslLanguageFeatures.has("uniform_buffer_standard_layout")) {<br>throw new Error(`WGSL uniform buffer standard layout is not available`);

const adapter = await navigator.gpu.requestAdapter();<br>const device = await adapter.requestDevice();

const shaderModule = device.createShaderModule({ code: `<br>requires uniform_buffer_standard_layout;

struct S {<br>x: f32<br>struct Uniforms {<br>a: S,<br>b: f32<br>// b is at offset 4. Without standard layout, alignment rules would<br>// force b to be at offset 16 (or a multiple of 16), and you would have<br>// to add extra fields or use an @align attribute.

@group(0) @binding(0) var u: Uniforms;

@fragment fn fs_main() -> @location(0) vec4 {<br>return vec4(u.a.x);<br>}`,<br>});

WebGPU on Linux

The Chrome team is carefully rolling out WebGPU for Linux, starting with support for Intel Gen12+ GPUs but with a tentative plan to expand it to more devices (AMD, NVIDIA). This implementation uses an architecture where WebGPU uses Vulkan and the rest of Chromium stays on OpenGL, exercising existing well known good code paths. See issue 442791440.

Faster writeBuffer and writeTexture

writeBuffer() and writeTexture() have been optimized in Chrome, resulting in performance gains up to 2X better than the previous version, depending on the size of the data being transferred. This change affects all users of the Dawn Wire implementation as well. See issue 441900745.

Dawn updates

The Android GPU team has published the first alpha release of Kotlin bindings for WebGPU on Android available using Jetpack. The androidx.webgpu package gives Android developers access to a modern GPU API using Kotlin, bypassing the legacy issues of OpenGL or the complexity of Vulkan—an exciting development for the ecosystem!

This covers only some of the key highlights. Check out the exhaustive list of commits.

What's New in WebGPU

A list of everything that has been covered in the What's New in...

subgroup_id webgpu wgsl chrome extension subgroups

Related Articles