What's New in WebGPU (Chrome 153-154)

François Beaufort
François Beaufort
GitHub

Published: September 15, 2026

WGSL buffer_view extension

The WGSL language extension buffer_view allows the data of a uniform, storage, or workgroup variable to be interpreted as multiple different types. This has a wide range of utility from conventional type-punning usages to partitioning a variable into multiple logical variables.

For safety and implementation simplicity, reinterpreted types can only be accessed using the following built-in functions:

  • bufferView<T>() interprets memory at a specific byte offset as a pointer to type T.
  • bufferArrayView<T>() creates a bounded array pointer with an explicit element count.
  • bufferLength() returns the byte size of the buffer.

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

requires buffer_view;

//  +-------------------+-----------------------------+----------------------------+
//  | Byte 0 .. 3       | Byte 4 .. (4 + N - 1)       | Byte (4 + N) .. End        |
//  +-------------------+-----------------------------+----------------------------+
//  | indices_size (u32)| indices (array<u32, count>) | vertices (array<f32>)      |
//  +-------------------+-----------------------------+----------------------------+
@group(0) @binding(0) var<storage> indices_and_vertices : buffer;

fn unpack_and_process_geometry() {
  let indices_size = *bufferView<u32>(&indices_and_vertices, 0);

  let indices = bufferArrayView<array<u32>>(&indices_and_vertices, 4, indices_size);
  let vertices = bufferView<array<f32>>(&indices_and_vertices, indices_size + 4);
  ...
}

You can also check out the buffer view proposal for more details and play with the Wireframe WebGPU sample.

WGSL swizzle_assignment extension

In response to one of the most highly requested community features, the WGSL extension swizzle_assignment lets you write directly to vector swizzles, enabling you to update multiple components in a single statement. It drastically reduces boilerplate and improves shader readability while bringing WGSL in line with other shading languages.

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

if (!navigator.gpu.wgslLanguageFeatures.has("swizzle_assignment")) {
  throw new Error(`WGSL swizzle assignment is not available`);
}

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

const shaderModule = device.createShaderModule({ code: `
  requires swizzle_assignment;

  @vertex
  fn main(@builtin(vertex_index) vertex_index: u32) -> @builtin(position) vec4f {
    var position = vec4f(0.0, 0.0, 0.0, 1.0);
    position.xy = vec2f(10.0, 20.0); // Swizzle assignment

    return position;
  }`,
});

WGSL extension updates

The texture-formats-tier1 language extension, although supported in WGSL code, was previously not properly mapped to navigator.gpu.wgslLanguageFeatures (as texture_formats_tier1) in JavaScript. This mapping issue has now been resolved. See Chromium CL 8159562.

The subgroups language extension is now automatically enabled when subgroup_size_control is enabled in WGSL. See issue dawn:545285663.

Dawn updates

The new wgpu::FeatureName::BufferMapWriteExtendedUsages experimental feature lets you create a buffer with wgpu::BufferUsage::MapWrite combined with any other wgpu::BufferUsage, except wgpu::BufferUsage::MapRead to write directly into a mappable buffer that is also GPU-usable, eliminating the staging buffer and the extra copy on Vulkan and D3D12 backends. For more information, see Buffer Map Write Extended Usages and issue dawn:386255678.

You can now use the webgpu_cpp.h bindings on top of any webgpu.h implementation instead of being tied to Dawn's flavor by using new webgpu_upstream_cpp_headers. See webgpu-headers issue #596.

Dawn now requires macOS 13.0 or later. See Dawn CL 334415.

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

What's New in WebGPU

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

Chrome 153-154

Chrome 151-152

Chrome 149-150

Chrome 147-148

Chrome 146

Chrome 145

Chrome 144

Chrome 143

Chrome 142

Chrome 141

Chrome 140

Chrome 139

Chrome 138

Chrome 137

Chrome 136

Chrome 135

Chrome 134

Chrome 133

Chrome 132

Chrome 131

Chrome 130

Chrome 129

Chrome 128

Chrome 127

Chrome 126

Chrome 125

Chrome 124

Chrome 123

Chrome 122

Chrome 121

Chrome 120

Chrome 119

Chrome 118

Chrome 117

Chrome 116

Chrome 115

Chrome 114

Chrome 113