Novedades de WebGPU (Chrome 146)

François Beaufort

Publicado: 25 de febrero de 2026

Se agregó compatibilidad con el modo de compatibilidad de WebGPU en OpenGL ES 3.1

Si bien WebGPU está diseñado para alinearse con las APIs de gráficos modernas, como Vulkan, Metal y D3D12, muchos usuarios tienen hardware más antiguo que no admite estos estándares. Para subsanar esta brecha y garantizar una amplia accesibilidad, Chrome presenta una nueva función opcional llamada modo de compatibilidad.

Este modo te permite ejecutar WebGPU en APIs de gráficos más antiguas, como OpenGL ES 3.1. Si segmentas tu aplicación web para que se dirija a un subconjunto ligeramente restringido de la especificación de WebGPU, te aseguras de que todos puedan acceder a ella, desde los equipos de juegos más recientes hasta las laptops y los dispositivos móviles más antiguos. Si bien el equipo comenzó con Android, está explorando la compatibilidad con otros dispositivos, como ChromeOS con OpenGL ES 3.1 y Windows con Direct3D 11.

En muchas apps web, puedes habilitar el modo de compatibilidad pasando featureLevel: "compatibility" cuando llamas a requestAdapter(). Si tu dispositivo admite Core WebGPU, Chrome devolverá un adaptador compatible con Core, pero tu app web sabrá que debe permanecer dentro de los límites de compatibilidad, a menos que habilite la función "core-features-and-limits" (o habilite todas las funciones disponibles). Las aplicaciones más complejas pueden requerir ajustes menores para cumplir con las restricciones del modo.

// Request a GPUAdapter in compatibility mode.
const adapter = await navigator.gpu.requestAdapter({ featureLevel: "compatibility" });
const device = await adapter.requestDevice();

Consulta la guía de conceptos básicos de WebGPU para obtener información detallada sobre las restricciones arquitectónicas específicas de este modo. Además, todas las muestras de WebGPU ahora admiten el modo de compatibilidad. También puedes leer la intención de envío.

Archivos adjuntos transitorios

Puedes usar la nueva marca TRANSIENT_ATTACHMENT GPUTextureUsage para crear archivos adjuntos eficientes en cuanto a la memoria. Esto permite que las operaciones de pase de renderizado permanezcan en la memoria de la segmentación, lo que evita el tráfico de VRAM y la asignación de VRAM para las texturas.

Cuando se declara una textura como transitoria (o "sin memoria"), la GPU sabe que solo necesita el contenido de la textura de forma temporal, específicamente, solo dentro del pase de renderización actual. Además, debido a que el contenido de la textura se descarta después del pase de renderización, es posible que el controlador no necesite asignar VRAM para ella.

En el siguiente ejemplo, se muestra cómo crear una textura transitoria.

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

if ('TRANSIENT_ATTACHMENT' in GPUTextureUsage) {

  const transientTexture = device.createTexture({
    size: [42, 42],
    // The TRANSIENT_ATTACHMENT flag indicates the texture content is temporary,
    // potentially keeping it in fast on-chip memory.
    usage: GPUTextureUsage.RENDER_ATTACHMENT | GPUTextureUsage.TRANSIENT_ATTACHMENT,
    format: 'rgba8unorm',
  });
}

Consulta la muestra de Hello Triangle MSAA - WebGPU y la intención de lanzamiento.

Extensión texture_and_sampler_let de WGSL

La extensión de lenguaje WGSL texture_and_sampler_let te permite asignar variables de textura o de muestreador a un let dentro de un sombreador de WGSL. Actualmente, esta función proporciona un mecanismo de nomenclatura alternativo y prepara la compatibilidad sin vinculación, en la que los métodos que devuelven texturas o muestras se pueden almacenar directamente en variables locales.

Consulta el siguiente ejemplo y la intención de lanzamiento.

@group(0) @binding(0) var tex: texture_2d<f32>;
@group(1) @binding(0) var store : texture_storage_2d<r32float, read_write>;

@fragment fn main() {
    let a = tex;
    var res: vec4f = textureLoad(a, vec2i(1i), 0);

    textureStore(store, vec2i(0i), res);
}

Actualizaciones de Dawn

Los siguientes niveles de límites nuevos están disponibles:

maxStorageBuffersPerShaderStage admite hasta 16. Consulta el problema 366151398.
maxSampledTexturesPerShaderStage admite hasta 48. Consulta el problema 475255737.

La validación de SPIR-V está habilitada de forma predeterminada en Android para proporcionar una capa de seguridad adicional y evitar la inestabilidad del controlador debido a entradas con formato incorrecto. Consulta el problema 473526182.

Esto solo abarca algunos de los aspectos destacados clave. Consulta la lista exhaustiva de confirmaciones.

Novedades de WebGPU (Chrome 146)

Se agregó compatibilidad con el modo de compatibilidad de WebGPU en OpenGL ES 3.1

Archivos adjuntos transitorios

Extensión texture_and_sampler_let de WGSL

Actualizaciones de Dawn