Hacia dónde va la computación gráfica en la web
Las extensiones que el grupo de trabajo discute, por qué el ray tracing por hardware depende de otra cosa, la relación con WebNN, y cómo seguir esto sin creerte los titulares.
La última lección del track es la que más rápido caduca, así que vale la pena escribirla de forma que envejezca bien: no como una lista de promesas, sino como el mapa de qué se está discutiendo, qué depende de qué, y por qué las cosas que parecen inminentes llevan años sin llegar. Con eso podrás leer cualquier anuncio dentro de dos años y saber si es una noticia o un titular.
- Enumerar las extensiones que el grupo de trabajo discute y el estado real de cada una.
- Explicar por qué el ray tracing y los mesh shaders dependen de una tercera cosa.
- Situar WebNN respecto a WebGPU sin confundir sus alcances.
- Seguir la evolución de la especificación en la fuente y no en los resúmenes.
Lo que está en discusión
Lo primero que hay que entender del proceso es su forma: WebGPU no crece cambiando el núcleo, crece añadiendo features opcionales. Ya has visto el patrón en el nivel anterior con subgroups, primitive-index, texture-component-swizzle o los niveles de formatos de textura. Ninguna de ellas cambió lo que ya funcionaba; todas hay que comprobarlas antes de pedirlas. Esa es la forma que van a tener también las que vengan, y por eso la habilidad de negociar capacidades que aprendiste en el nivel 45 no es un detalle de portabilidad: es el mecanismo por el que vas a poder usar todo lo que llegue.
Lo que está sobre la mesa, ordenado por lo que de verdad importa:
Bindless. Es la pieza central y la que desbloquea el resto. Hoy, un shader accede a los recursos que hay en sus bind groups y a nada más, con maxStorageBuffersPerShaderStage en 8 y maxSampledTexturesPerShaderStage en 16. Bindless significa que un shader pueda indexar dinámicamente un array de miles de texturas y buffers sin declararlos uno a uno. Suena a comodidad y es mucho más que eso: es el requisito de cualquier algoritmo que necesite información de la escena entera dentro de un shader, que es exactamente lo que hacen el ray tracing, los mesh shaders y las técnicas de geometría virtualizada. El grupo de trabajo lo tiene en fase de diseño y es un problema difícil por la razón que hace difícil todo en la web: hay que darle una semántica segura, sin accesos fuera de rango y sin filtrar memoria ajena, encima de tres APIs nativas que lo resuelven de formas distintas.
Multi-draw indirect. Emitir muchos dibujados con un solo comando, con el número de dibujados decidido por la GPU. Es la pieza que falta para cerrar el renderizado dirigido por GPU: hoy, aunque generes el buffer indirecto en compute, sigues necesitando una llamada por objeto desde la CPU o meterlo todo en un único dibujado con instancing. Hay soporte experimental tras un flag en Chromium desde hace varias versiones, y no está en la especificación.
Matrices cooperativas de subgrupo. Operaciones de multiplicación de matrices pequeñas ejecutadas en bloque por un grupo de hilos, que es como el hardware moderno expone sus unidades de tensor. Es lo que separa una implementación de inferencia razonable de una rápida, y está en discusión, no estandarizado.
El modo de compatibilidad. Ya lo has visto: featureLevel: 'compatibility', experimental en Chromium desde Chrome 146 y solo en Android con OpenGL ES 3.1 o superior. Va en la dirección contraria a todo lo anterior (no añade potencia, amplía cobertura) y por eso mismo puede acabar siendo el cambio con más impacto real en cuántos usuarios pueden ejecutar lo que escribes.
Mesh shaders. Sustituir la etapa de vértices por un modelo de cómputo que genera geometría directamente. Es una de las cosas que más se piden y está detrás de bindless en la cola.
El ray tracing por hardware y por qué no llega
Es la pregunta que más se repite, y merece una respuesta honesta y no una esperanza.
Las tres APIs nativas tienen aceleración de rayos por hardware desde hace años: Direct3D 12 con DXR, Vulkan con su extensión de ray tracing, Metal con la suya. Existen incluso implementaciones no oficiales que la exponen a través de la implementación de WebGPU de Chrome, hechas fuera del proceso de estandarización. Y aun así, el ray tracing por hardware no está en WebGPU ni tiene fecha.
Las razones son tres y ninguna es “no lo han pensado”.
La primera es la dependencia técnica: un shader de intersección o de sombreado de impacto necesita, por definición, acceder a los materiales y a las texturas de cualquier objeto que el rayo golpee, y eso es acceso a la escena entera desde el shader. Sin bindless no hay forma de expresarlo. El ray tracing está detrás de bindless en la cola porque no puede ir delante.
La segunda es la portabilidad, que es la restricción que define a WebGPU. Añadir una capacidad que solo existe en una fracción de las GPU choca con la razón de ser de la especificación, y aunque el mecanismo de features opcionales lo permitiría técnicamente, el coste de mantener dos caminos muy distintos en el mismo motor es alto.
La tercera es la superficie de seguridad. Las estructuras de aceleración las construye el driver, viven en memoria que la aplicación no controla del todo, y hacerlas seguras frente a un contenido web hostil es un trabajo considerable.
Lo que sí puedes hacer hoy es lo del nivel 38: trazar por software en compute shaders, con tu propia BVH y tu propio recorrido. Es más lento que el hardware por un factor grande, y aun así llega perfectamente para imágenes progresivas, previsualización y configuradores, que es donde el trazado tiene sentido en la web de todos modos.
WebGPU y WebNN
Conviene tener claro el reparto, porque los dos nombres aparecen juntos y resuelven cosas distintas.
WebGPU es una API de propósito general sobre la GPU: tú escribes el kernel y decides cómo se ejecuta. WebNN es una API de más alto nivel que expone un grafo de operaciones de red neuronal y deja que la implementación lo ejecute donde mejor pueda, que puede ser la GPU, la CPU o un acelerador dedicado del dispositivo. La diferencia práctica: con WebGPU escribes la multiplicación de matrices con tiling que viste en el nivel 37; con WebNN describes la red y no escribes ningún kernel.
El estado a mediados de 2026, con los matices que importan: el W3C publicó una Candidate Recommendation actualizada de WebNN en enero de 2026, con más de cien cambios significativos respecto a la instantánea anterior, incluida una tercera tanda de operadores pensada para transformers, una API de tensores para compartir buffers, y un mecanismo de selección de dispositivo. Es un avance real de la especificación. Y a la vez, WebNN no está listo para producción: en Chromium sigue en pruebas de origen, y fuera de compilaciones experimentales no hay soporte de navegador con el que puedas contar.
La consecuencia práctica es la que ya está pasando: el camino real para ejecutar modelos en el navegador hoy es WebGPU, a través de librerías como las que usan el tiempo de ejecución de ONNX en la web o las bibliotecas de transformers en JavaScript, que compilan sus operadores a WGSL. Si tu proyecto necesita inferencia en el cliente, esa es la ruta; WebNN es el destino a medio plazo y la ventaja que promete no es la velocidad bruta sino el acceso a aceleradores que WebGPU no puede tocar.
Y hay un punto de contacto que conviene vigilar y que es donde se juega la utilidad de todo esto: si el modelo corre en un sitio y tu render en otro, la copia de datos entre ambos se come la ganancia. La compartición eficiente de tensores entre las dos APIs es exactamente el problema que la nueva API de tensores de WebNN intenta resolver, y es el detalle técnico que decidirá si merece la pena migrar.
Qué esperar, y cómo seguirlo
Tres expectativas calibradas, que es lo mejor que se puede ofrecer sin inventar fechas.
Lo que llegará razonablemente pronto son más features opcionales del estilo de las que ya existen: más formatos de textura, más operaciones de subgrupo, más capacidades acotadas que no cambian el modelo. Son incrementales y no te obligan a rediseñar nada.
Lo que llegará cuando llegue es bindless, y con él la posibilidad de que se abra la puerta a lo demás. Es la que hay que vigilar, porque es la que cambia qué algoritmos son expresables.
Lo que puede que no llegue nunca en la forma que imaginas es el ray tracing por hardware. Puede aparecer acotado, en una forma más limitada que la nativa, o puede que la respuesta sea otra: que el trazado por software siga mejorando lo suficiente y que la diferencia deje de importar para lo que se hace en la web.
Para seguirlo sin depender de titulares, tres fuentes y un método. El repositorio del grupo de trabajo, donde las propuestas viven como incidencias abiertas con la discusión completa, y donde se ve quién tiene reservas y por qué, que es información que ningún resumen conserva. Las notas de versión de las implementaciones, que cuentan qué se ha enviado de verdad y detrás de qué flag. Y los datos de compatibilidad de navegadores, que son la única respuesta fiable a la pregunta de si algo funciona en el dispositivo de tu usuario.
El método consiste en no mezclar nunca cuatro preguntas que se responden en sitios distintos: si algo se discute, si está en la especificación, si un motor lo ha implementado, y si el dispositivo del usuario lo ejecuta. Los titulares colapsan las cuatro en una. La mayoría de las decepciones con la plataforma web vienen de leer la primera y entender la cuarta.
Es tentador leer todo lo anterior como una lista de carencias: sin ray tracing, sin bindless, sin mesh shaders, con maxBindGroups clavado en 4 y con un modo de compatibilidad que apunta a hardware de hace más de una década. Y desde la perspectiva de quien viene de programar una consola o Vulkan, lo es. Pero conviene mirar qué compra esa restricción, porque es una operación que ninguna otra plataforma gráfica puede hacer: un shader que escribes hoy se ejecutará dentro de diez años en hardware que todavía no existe, en un dispositivo que no elegiste, para un usuario que no instaló nada. Ese es el trato entero de la web y siempre ha sido el mismo. Direct3D 12 puede permitirse exponer la última extensión del último modelo de una marca porque su contrato es con un ecosistema controlado; WebGPU no puede, porque su contrato es con todos los dispositivos a la vez y para siempre. Por eso el proceso es lento, por eso las capacidades nuevas llegan como features opcionales negociables, y por eso el diseño rechaza cualquier cosa que no se pueda hacer segura sobre tres backends distintos. La consecuencia para ti, que es lo único que importa a estas alturas del track, es que el esfuerzo que has invertido en aprender a diseñar contra el contrato mínimo no es una limitación que estás sufriendo: es la habilidad que hace que lo que escribas siga funcionando. Los motores nativos se reescriben cada generación de hardware. El tuyo, si lo has hecho como se cuenta en este nivel, va a seguir corriendo cuando el ray tracing por hardware llegue a la web, cuando llegue bindless, y cuando la GPU que tienes ahora esté en un museo. Eso vale más que cualquier extensión.
- Busca en el repositorio del grupo de trabajo la discusión sobre bindless y lee los argumentos en contra, no solo la propuesta.
- Coge tres anuncios recientes sobre WebGPU y clasifícalos en las cuatro preguntas: se discute, está en la especificación, se ha implementado, se ejecuta en el dispositivo de tu usuario.
- Comprueba en tu navegador si
featureLevel: 'compatibility'te devuelve un adaptador y si tienecore-features-and-limits. - Escribe, en un párrafo, qué parte de tu proyecto tendrías que cambiar el día que llegue bindless. Si la respuesta es “casi nada”, tu arquitectura está bien.