Notas sobre WebGPU¶

7 minutos de lectura · 10 abril 2026

WebGPU lleva años "a punto de estar listo". En 2026 está, por fin, casi listo. Chrome y Safari lo soportan en estable; Firefox detrás pero avanza. Lo que queda son las esquinas: WGSL, tooling y debugging.

WebGPU no es "WebGL pero mejor". Es una abstracción más cercana a Vulkan/Metal con todo lo bueno y todo lo doloroso.

Lo que sigue son las notas que me hubiera gustado leer antes de gastar tres semanas en mi primer proyecto serio.

El cambio mental respecto a WebGL¶

WebGL se diseñó como abstracción sobre OpenGL ES 2.0. Esto significa: estado global mutable, drivers compensando por ti, optimizaciones implícitas.

WebGPU asume que tú sabes lo que haces:

• Pipelines explícitos. Defines un GPURenderPipeline o GPUComputePipeline con todo el estado de antemano. Cambiar de pipeline es caro; intentas no hacerlo.
• Bind groups en lugar de uniformes sueltos. Los recursos van en grupos predeclarados con un layout. Es más verboso. Es también predecible.
• Command encoders. Construyes una lista de comandos y los envías de golpe. Sin draw calls aislados.

La primera semana lo odias. La segunda empiezas a apreciar que el código sea más predecible. La tercera te das cuenta de que las optimizaciones que en WebGL eran magia oculta, en WebGPU son explícitas y por eso las puedes razonar.

WGSL: el lenguaje que te toca aprender¶

WebGPU no usa GLSL. Usa WGSL, un lenguaje propio. Es como Rust + HLSL en sintaxis. Razonable, escueto, sin sorpresas. Pero es otro lenguaje, y eso significa:

• Tu vertex/fragment shader hay que reescribirlo. Hay convertidores GLSL → WGSL pero no son perfectos.
• El tooling de syntax highlight + LSP está naciendo. Espera fricción.
• Documentación oficial es decente pero ejemplos completos escasean.

@vertex
fn vs_main(@location(0) pos: vec3f) -> @builtin(position) vec4f {
    return vec4f(pos, 1.0);
}

@fragment
fn fs_main() -> @location(0) vec4f {
    return vec4f(1.0, 0.5, 0.0, 1.0);
}

Si vienes de GLSL, lo lees del tirón. Si vienes de cero, también.

Cómputo: aquí está el dinero¶

Lo más interesante de WebGPU no es renderizado. Es cómputo de propósito general en GPU desde el navegador. Cosas que en 2024 requerían WebAssembly + SIMD para acercarse, ahora se hacen en compute shaders sin esfuerzo.

Casos reales que probé:

• Inferencia ONNX en GPU. onnxruntime-web con backend WebGPU da factores 10x sobre WASM en modelos chicos.
• Procesamiento de imágenes. Convoluciones, filtros, debruido. Las hago en compute shader; latencia interactiva con webcam de 4K.
• Simulaciones físicas / partículas. Cien mil partículas a 60fps en un MacBook Air no es tan distinto a un demo nativo.

El cuello de botella ya no es "el navegador no llega". Es "no sé escribir buen código WGSL".

Las esquinas que duelen¶

1. Debugging. No hay equivalente a gl_FragColor = vec4(uv, 0, 1) que sea trivial. Hay que sacar buffers, leerlos en JS y console.log. Renderdoc + Chrome funciona, pero requiere setup.
2. Soporte móvil. Android va. iOS estable solo desde Safari 17. Antes de eso, pantalla negra.
3. Memoria. Crear buffers/textures por frame mata el rendimiento. Hay que reusar agresivamente. WebGPU no recolecta como WebGL.
4. Compatibility mode. WebGPU "ligero" para dispositivos sin GPU moderna está en discusión. Mientras tanto, fallback a WebGL es obligado para producción seria.

Para qué empezaría hoy en WebGPU¶

• Cualquier cosa con compute pesado en GPU: ML, simulación, image processing.
• Visualización de datos grande (millones de puntos) donde WebGL ya cruje.
• Demos / prototipos donde el control fino justifica la curva.

Para qué seguiría con WebGL¶

• Compatibilidad con dispositivos viejos y mercado masivo.
• Stack ya escrito y funcionando. Migrar por migrar es caro y aporta poco si no aprovechas compute.
• Librerías 3D maduras (three.js, babylon.js) donde WebGPU como backend aún no está al 100%.

¿Comentarios o correcciones? info@encodigo.es.