WebGPU: cómo programar la GPU desde el navegador en 2026

Durante 25 años, programar gráficos 3D en el navegador significó WebGL: una API heredada de OpenGL ES 2.0, diseñada en 2007 y atada a un modelo de estado global lleno de funciones tipo gl.bindBuffer() que el navegador no puede paralelizar. En 2026 eso cambia: WebGPU es estándar W3C, está activo por defecto en Chrome, Edge, Firefox y Safari, y trae al navegador el modelo de las APIs modernas (Vulkan, Metal, Direct3D 12) más algo que WebGL nunca tuvo: cómputo paralelo de propósito general.

Qué es WebGPU

WebGPU es una API JavaScript (también disponible en Rust, C++ vía wgpu y Dawn) que le da a una página web acceso directo y seguro a la GPU del dispositivo. La GPU es ese chip dedicado que tu computadora o teléfono usa para dibujar pixeles en pantalla, pero también es un monstruo de cálculo: miles de núcleos pequeños trabajando en paralelo, ideales para multiplicar matrices, procesar imágenes, simular física o entrenar modelos de IA.

La diferencia clave con WebGL es filosófica. WebGL era una capa fina sobre OpenGL: el driver hacía gran parte del trabajo en tiempo de ejecución, lo que generaba CPU overhead y comportamiento impredecible entre dispositivos. WebGPU sigue el modelo de Vulkan: el programador describe explícitamente todo (memoria, layouts, pipelines) una sola vez al inicio, y el navegador lo traduce a la API nativa del sistema operativo (Direct3D 12 en Windows, Metal en macOS/iOS, Vulkan en Linux/Android).

Cómo funciona: los conceptos clave

Adapter y Device — El adapter es la GPU física (puede haber varias: integrada y dedicada). El device es tu conexión lógica con ella, sobre la que creas todo lo demás.
Buffers y Textures — Memoria en la GPU. Los buffers guardan datos arbitrarios (vértices, parámetros, resultados). Las textures guardan imágenes 2D o 3D con formatos optimizados.
Shaders en WGSL — Programas que corren dentro de la GPU. WebGPU usa su propio lenguaje, WGSL (WebGPU Shading Language), inspirado en Rust y diseñado para ser seguro y portable.
Pipelines — La receta completa: qué shader ejecutar, qué formato tienen los datos de entrada, cómo mezclar colores. Se compila una vez y se reutiliza miles de frames.
Bind groups — Paquetes de recursos (buffers, texturas) que el shader puede leer. Permiten cambiar parámetros sin recompilar el pipeline.
Command encoders — Tú no le hablas a la GPU directamente: armas una lista de comandos en la CPU y se la envías de un saque, lo que reduce overhead drásticamente.

Hello triangle: el ejemplo mínimo

Esto es lo mínimo necesario para dibujar un triángulo en un canvas. Lo simplificamos por espacio, pero ilustra el flujo:

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

const canvas  = document.querySelector('canvas');
const context = canvas.getContext('webgpu');
const format  = navigator.gpu.getPreferredCanvasFormat();
context.configure({ device, format });

const shader = device.createShaderModule({ code: `
  @vertex fn vs(@builtin(vertex_index) i: u32) -> @builtin(position) vec4f {
    let p = array(vec2f(0,0.6), vec2f(-0.6,-0.6), vec2f(0.6,-0.6));
    return vec4f(p[i], 0, 1);
  }
  @fragment fn fs() -> @location(0) vec4f {
    return vec4f(0.2, 0.8, 1.0, 1.0);
  }
`});

const pipeline = device.createRenderPipeline({
  layout: 'auto',
  vertex:   { module: shader, entryPoint: 'vs' },
  fragment: { module: shader, entryPoint: 'fs', targets: [{ format }] },
  primitive:{ topology: 'triangle-list' },
});

const encoder = device.createCommandEncoder();
const pass = encoder.beginRenderPass({
  colorAttachments: [{
    view: context.getCurrentTexture().createView(),
    clearValue: [0,0,0,1], loadOp: 'clear', storeOp: 'store',
  }],
});
pass.setPipeline(pipeline);
pass.draw(3);
pass.end();
device.queue.submit([encoder.finish()]);

Lo que pasa: pedimos un adapter, creamos el device, configuramos el canvas, definimos un shader WGSL con dos funciones (una por vértice, una por pixel), armamos un pipeline, grabamos comandos y los enviamos. La GPU hace el resto en microsegundos.

Compute shaders: la verdadera revolución

WebGL solo sabía dibujar. WebGPU también sabe calcular. Un compute shader es un programa que no genera pixeles; opera sobre buffers de datos en paralelo, agrupando hilos en "workgroups" que se ejecutan simultáneamente:

@group(0) @binding(0) var<storage, read>       input:  array<f32>;
@group(0) @binding(1) var<storage, read_write> output: array<f32>;

@compute @workgroup_size(64)
fn main(@builtin(global_invocation_id) id: vec3u) {
  output[id.x] = input[id.x] * 2.0;
}

Esto duplica un millón de números en paralelo en menos de un milisegundo. El mismo patrón sirve para multiplicar matrices, aplicar filtros de imagen, simular partículas o ejecutar modelos de IA. Proyectos como WebLLM ya corren modelos como Llama 3 enteros en el navegador usando compute shaders WebGPU, sin servidor.

WGSL: el lenguaje propio

WGSL es uno de los aportes más interesantes del estándar. Estuvo años en debate (¿adoptar HLSL? ¿GLSL? ¿SPIR-V?) y al final el W3C diseñó un lenguaje nuevo: tipado estricto, sintaxis tipo Rust, sin punteros sueltos, con reglas estrictas para evitar comportamiento indefinido. Es seguro de ejecutar incluso si viene de una página maliciosa: el navegador valida el código antes de pasarlo a la GPU, garantizando que un shader no pueda leer memoria fuera de sus buffers asignados.

Por qué importa

Rendimiento real — Mediciones publicadas por el equipo de Chrome muestran 3x-10x menos CPU overhead que WebGL en escenas complejas, lo que se traduce en frame rate estable en laptops modestas.
IA en el cliente — Inferencia local de modelos medianos (1B-8B parámetros) sin enviar datos a un servidor. Implicaciones de privacidad enormes: tu prompt nunca sale del navegador.
Cómputo científico — Simulaciones, visualizaciones de datos, procesamiento de imágenes médicas, todo dentro de una pestaña sin instalar nada.
Juegos AAA en la web — Engines como Unity, Unreal y Babylon.js ya soportan WebGPU como backend. Los port web dejan de ser "versiones reducidas".
Más allá del navegador — La librería wgpu (Rust) y Dawn (C++) implementan el estándar fuera del navegador, así que el mismo código WebGPU corre como aplicación nativa, en Node.js o en Deno.

Limitaciones a considerar

No todo es perfecto. WebGPU exige hardware razonablemente moderno (GPU compatible con Vulkan 1.1, Metal 2 o D3D 12), por lo que dispositivos de hace 8+ años quedan fuera. La curva de aprendizaje es más empinada que WebGL: hay que entender bind groups, layouts y pipelines explícitos antes de pintar el primer triángulo. Y aunque la API ya es estable, el ecosistema de tutoriales y librerías sigue madurando.

Cómo empezar hoy

La ruta recomendada en 2026: leer la guía oficial de MDN sobre WebGPU, probar las samples interactivas en webgpu-samples, y para proyectos serios apoyarse en una capa de abstracción como Three.js (que ya tiene renderer WebGPU) o Babylon.js, hasta que sintamos cuándo bajar al nivel crudo de la API.

Conclusión

WebGPU no es una mejora incremental de WebGL: es un cambio de capa. Pone en manos del desarrollador web la misma potencia que tienen los desarrolladores nativos desde hace una década, con la portabilidad que solo ofrece la web. La consecuencia práctica es que en los próximos años veremos editores de video, herramientas de diseño 3D, juegos serios y modelos de IA completos corriendo en una pestaña, sin servidor y sin instalación. La era del navegador como plataforma de cómputo serio recién empieza.

📖 Versión extendida con más detalle: https://elsolitario.org/2026/05/07/webgpu-programar-gpu-navegador-2026/?utm_source=telegraph&utm_medium=instant_view&utm_campaign=programacion