Desbloquear la informática con GPU usando WebGPU

Hola, soy Mike, ingeniero del equipo Safari. Hoy te mostraré cómo WebGPU te permite acceder a computación paralela en la GPU desde la web. En cuanto a gráficos 3D, WebGPU hace lo mismo que WebGL, pero con mucho mayor rendimiento y flexibilidad. Es la mejor opción para gráficos en la web. Además, es la única forma de ejecutar cálculos generales en la GPU directamente en el navegador. Si estás familiarizado con Metal, te sentirás como en casa. La mayoría de las llamadas son asignaciones uno a uno con la estructura Metal. De hecho, es compatible con plataformas compatibles con Metal, como: la Mac, el iPhone, el iPad y Vision Pro. Al ser una API web, los sitios web y las apps que usan WebGPU se ejecutarán donde sea compatible. En sistemas que no son de Apple, se implementa con API similares a Metal. Si no estás familiarizado con la programación de gráficos de bajo nivel, puedes usar muchas bibliotecas de gráficos web para tener acceso a todo el rendimiento y las capacidades que ofrece WebGPU. Puedes usar threeJS ejecutando WebGPU en segundo plano para animar estas magníficas medusas 3D en tiempo real. Es un ejemplo sorprendente y funciona de maravilla en Safari, gracias a que WebGPU se desarrolló para aprovechar al máximo el hardware moderno actual. Primero, exploraremos la API y la aplicación de WebGPU a Metal. Esto explicará gran parte del código necesario para cualquier aplicación WebGPU. Luego, veremos cómo crear sombreadores WebGPU: código que se ejecuta directo en la GPU. Veremos el lenguaje de sombreado y la necesidad de uno nuevo para la web.

Después de cubrir los conceptos básicos, veremos cómo obtener el mejor rendimiento con la API. Si estás familiarizado con WebGPU, será muy interesante conocer optimizaciones específicas para las plataformas de Apple. Comencemos con una mirada rápida a la canalización de gráficos.

Se puede pensar que el canal fluye de izquierda a derecha. Comienza con contenido cargado en tu sitio web o app: imágenes, videos o datos binarios.

Luego, ese contenido pasa a WebKit, que es responsable de prepararlo para la GPU.

WebKit llama a la estructura Metal para crear los recursos y programas que se ejecutarán directamente en el hardware gráfico.

Analicemos esto. En WebGPU, Metal genera tres tipos de recursos: buffers, texturas y samplers. WebKit los organiza en un grupo llamado grupo de enlace de la GPU. Una forma estructurada de agrupar recursos para que la GPU pueda utilizarlos de manera eficiente. Más a detalle, estos están empaquetados en un búfer de argumentos, un búfer de Metal con referencias a los recursos reales de la GPU. Los programas en sí provienen de cadenas de código y se compilan en tres tipos principales: Programas de cálculo, vértices y fragmentos. Estas son las instrucciones reales que se ejecutan en la GPU haciendo desde cálculos hasta representaciones de píxeles en la pantalla. Con una comprensión sólida del lugar de los recursos y programas, veamos una descripción general de cómo WebGPU define las diferentes interfaces en su API.

WebGPU es una API plana, pero tiene muchas interfaces. En la parte superior de la jerarquía están las interfaces de objetos GPU y adaptadores GPU.

A menudo se utiliza un canvas con WebGPU. Canvas ahora puede devolver un GPUCanvasContext consultando el contexto WebGPU.

Un dispositivo es la entrada principal para la mayoría de las llamadas. Es lo que se utiliza para crear la mayoría de las otras interfaces.

Si bien hay muchas interfaces diferentes en la API, se simplifican en unas pocas categorías. Es decir, recursos como texturas, buffers y samplers.

Codificadores, que emiten comandos sobre los recursos. Canales, que indican cómo los codificadores deben interpretar los distintos recursos. Grupos de enlace, que agrupan recursos relacionados. Y módulos de sombreado, que contienen instrucciones para ejecutar cálculos en la GPU. Ahora que comprendemos la estructura general de WebGPU, veamos cómo trabajar con la API y crear el dispositivo y los recursos.

Un dispositivo es la entrada principal de la mayoría de las llamadas. Si estás familiarizado con Metal, es muy similar a MTLDevice.

Si tienes una página con canvas, comienza por obtener el elemento canvas. Luego, usa navigator.gpu.requestAdapter() para crear un adaptador y llamar a requestDevice para crear tu dispositivo GPU.

WebGPU admite varias extensiones, por ejemplo, shader-f16, que permite utilizar flotantes de media precisión.

Estos ayudan al rendimiento y reducen el ancho de banda de la memoria. Aunque es compatible con todos los dispositivos Apple, es una función opcional. Verifica la compatibilidad antes de usarla en otras plataformas.

Luego, configura el contexto del canvas al llamar a configure. Esto vincula el canvas a la memoria en la que la GPU puede escribir.

Ahora que el dispositivo está listo, puedo crear algunos recursos. En WebGPU, trabajarás mucho con buffers y texturas. En Metal, están representados por MTLBuffer y MTLTexture.

Los buffers son muy flexibles. Puedes usarlos para almacenar todo tipo de datos, desde un vector de flotantes hasta datos personalizados más complejos que tu definas. Por ejemplo, puedes tener un búfer con varias instancias de un tipo de partícula. Imagina tres partículas almacenadas en el búfer.

Se crea un búfer llamando a createBuffer en el dispositivo. Pasando el tamaño del buffer y un modo de uso. El modo de uso permite que WebGPU evite carreras de datos sin más complejidades de API.

El dispositivo tiene una propiedad llamada fila, que sirve para realizar operaciones en buffers y texturas.

Una vez creado el buffer, completa tu contenido llamando a writeBuffer, pasando el buffer, un desplazamiento y un arrayBuffer de JavaScript.

Como los buffers, las texturas son bloques de memoria, pero se asocian con registros de textura e instrucciones especiales en la GPU. Suelen ser una representación de algunos datos de imagen y pueden ser unidimensionales, bidimensionales, una matriz de texturas bidimensionales, un mapa cúbico, que es una matriz de seis texturas bidimensionales, o una textura tridimensional.

Para crear una textura, llama a device.createTexture, pasa el ancho y la altura de la textura, el formato de textura 2D y los modos de uso.

Después de crear GPUTexture, cargamos datos de imagen con device.queue.copyExternalImageToTexture pasando el mapa de bits de la imagen, la textura 2D creada y el tamaño de la imagen.

Una textura se crea a partir de datos de imagen y representa una imagen en la GPU. Después de crear un dispositivo y recursos, veamos cómo crear una canalización.

Un canal especifica cómo se utilizarán las texturas y los buffers en la GPU. Hay dos tipos de canalizaciones: canalizaciones de renderizado, para programas de vértices y fragmentos, y canalizaciones de cálculo, para programas de cálculo. Estos se asignan a objetos MTLRenderPipelineState y MTLComputePipelineState en Metal.

Para crear una canalización, llama a device.createComputePipeline pasando un diseño de grupo de enlace o el identificador automático constante, que genera un diseño a partir del sombreador.

Un diseño es una forma estructurada en la que los buffers, texturas y samplers se pasan desde la API al programa GPU.

Se requiere un módulo sombreador para crear la canalización. Se crea a partir de una cadena.

Las canalizaciones de renderizado se crean igual, con un diseño automático, un módulo de sombreador de vértices y un módulo de sombreador de fragmentos.

Una vez creados el dispositivo, los recursos y las canalizaciones, la configuración básica de WebGPU está completa.

Ya exploramos la arquitectura de la API WebGPU, ahora veamos cómo desarrollar sus sombreadores.

El lenguaje de sombreado WebGPU, o WGSL, permite a los sitios web escribir programas que se ejecutan en la GPU. Apple está involucrado en el diseño e implementación del lenguaje de sombreado WGSL. WGSL está diseñado desde cero para ser seguro para la web. WGSL admite tres tipos de programas: programas de vértices, de fragmentos y de cálculo.

Veamos cómo crear este ejemplo simple de WebGPU que se compone de: un programa de vértices, que toma datos de búfer de JavaScript y crea triángulos en la pantalla. Un programa de fragmentos que calcula valores de color y profundidad individuales de texturas. Y un programa de cálculo, que puede hacer cualquier cálculo, pero en este caso, será una simulación física.

El programa Vertex calcula dónde aparecen los triángulos en la pantalla.

Aquí podemos ver los contornos de los 100,000 triángulos que se utilizan en este ejemplo.

Para escribir la posición de salida de los triángulos, utiliza el atributo de posición @builtin.

Aquí están la definición de la función principal y las entradas del sombreador de vértices. Solo escribe la posición y un color. Ahora, veamos a un sombreador de fragmentos.

Toma el color que generamos en la etapa del vértice y almacena ese color en la textura. Este es un ejemplo simple, pero puedes insertar cualquier lógica para calcular valores de color y profundidad. Puedes escribir en texturas de almacenamiento, buffers, realizar operaciones atómicas y mucho más. WGSL es muy flexible. Ahora veamos algo aún más flexible: sombreadores de cómputo.

Al igual que otros programas, los sombreadores de cómputo pueden contener enlaces, o entradas de JavaScript a un sombreador.

Los sombreadores de cómputo son geniales porque puedes realizar cualquier cálculo, almacenar los resultados en búferes y volver a leer los búferes en tu código JavaScript. No es necesaria ninguna visualización en la pantalla. Los sombreadores de cómputo no eran posibles con WebGL, otra razón para utilizar WebGPU para nuevas aplicaciones.

El programa requiere un tamaño de grupo de trabajo que define el tamaño de la cuadrícula sobre la que se ejecutará el sombreador.

También usaremos global_invocation_id, que es la posición en toda la cuadrícula. Esta es una variable incorporada, que se puede utilizar sin pasar nada desde JavaScript.

El cuerpo del sombreador actualiza la simulación de partículas, aplicando gravedad, velocidad y tiempo transcurrido.

Puedes realizar cualquier cálculo en un sombreador de cómputo y se ejecutará en paralelo con un rendimiento increíble en la GPU.

Cuando partícula desaparece por completo, se elige un punto para que reaparezca llamando a textureLoad en un mapa de probabilidad y seleccionando una nueva posición.

Finalmente, el resto de los atributos de la partícula se restablecen a sus valores iniciales y esta se almacena en el búfer.

Al unirlo obtenemos esta linda animación con el logo de WebGPU. Al aprovechar las capacidades de procesamiento paralelo de la GPU, puedes realizar cálculos arbitrarios de tamaños que antes no eran posibles desde la web y lograr un rendimiento en tiempo real.

¿No es genial?

Esta fue un resumen de cómo desarrollar sombreadores para aplicaciones WebGPU. Ahora veamos cómo obtener el mejor rendimiento de WebGPU.

Hay algunas pautas a tener en cuenta que te ayudarán a ofrecer la mejor experiencia en las plataformas de Apple. Una clave para un gran rendimiento es ser consciente del uso de la memoria: utiliza datos con un uso eficiente de memoria, registra tus comandos de renderizado una vez y reutilízalos, emplea pocos recursos. Profundicemos en más detalles.

Hay un par de formas de minimizar el uso de memoria. Primero, utilizar flotantes de media precisión. Son un estándar IEEE. En WGSL, el tipo de datos se llama f16. Ayudan a reducir el uso de memoria y mejoran el rendimiento. Dicho esto, no siempre son prácticos. Asegura que tus algoritmos sean estables con precisión reducida y ten en cuenta que sus valores máximos rebasan 65,000, a diferencia de los flotantes de 32 bits que manejan valores superiores. En iOS y visionOS, almacenar datos en formato f16 o comprimido puede ayudarte a evitar que tu programa finalice debido a la presión de la memoria. Para utilizar estos flotantes, deberás habilitarlos durante la creación del dispositivo y en tu código WGSL. Veamos cómo hacer eso con un ejemplo de código rápido.

Primero, habilita la extensión shader-f16 en la llamada a requestDevice y, en el shader, agrega la declaración 'enable f16'.

Luego, puedes usar los tipos escalares y vectoriales f16, junto con todos los tipos de 32 bits. Incluso si simplemente almacenas los datos con media precisión y los descomprimes en f32, obtendrás beneficios de memoria para evitar que tu app finalice debido a la presión.

Otra forma de minimizar el uso de memoria es evitar llamadas innecesarias de actualización de buffer y textura. Estos requieren copias de datos de JavaScript en la memoria que respalda el recurso Metal. La actualización de buffers con modos de uso indirecto e índice puede ser costosa porque se necesita una validación antes de volver a utilizar el buffer. Estos buffers se indexan directa o indirectamente en buffers de vértices y WebGPU debe garantizar que todos los desplazamientos hacia ellos estén dentro de los límites antes de ejecutar cualquier comando.

Actualiza estos buffers solo cuando sea necesario. Esto también aplica en un grupo de enlace con acceso de escritura o de lectura/escritura. Como en el ejemplo de código, prefiere el acceso de solo lectura a menos que estés escribiendo a través del recurso en el sombreador, sobre todo si es un índice o un búfer indirecto. Seguir estos consejos de memoria impacta en el rendimiento, no solo en las plataformas de Apple, sino en todos los dispositivos móviles y de escritorio. Ahora hablemos de cómo reutilizar tus comandos de renderizado.

Los paquetes de renderizado son excelentes para esto, ya que permiten codificar comandos una vez y reproducirlos tanto como necesites. WebGPU debe asegurarse de que todas las lecturas y escrituras estén bien definidas y dentro de los límites, esto implica mucha validación en cada cuadro. Pero con los paquetes de renderizado, esa validación ocurre solo cuando se crea el paquete, en lugar de en cada ejecución. Esto ahorra tiempo y acerca tu app al rendimiento nativo, dejando más espacio para tu lógica real. Crear un paquete de renderizado es muy simple. Primero, crea un codificador de paquete de renderizado y luego codifica tus llamadas de dibujo, como con un codificador de paso de renderizado. Al llamar a finish() se crea el paquete para reutilizar.

Ahora que tienes un paquete, puedes ejecutar esos comandos de dibujo con una llamada a executeBundles() una y otra vez según sea necesario.

Los paquetes de renderizado se asignan a los buffers de comandos indirectos de Metal y brindan beneficios de rendimiento similares. Ya abordamos el uso de la memoria y la reducción de sobrecarga de validación, veamos ahora cómo reducir la cantidad de recursos.

Concretamente, buffers de comandos, pases de renderizado y cálculo, diseños de grupos de enlaces y grupos de enlaces.

Los límites del búfer de comandos requieren sincronización entre la memoria en chip de alta velocidad y la unificada en el dispositivo. Si es posible, utiliza un solo buffer de comando por bucle de actualización o, en su defecto, una buena regla general es que se debe utilizar la menor cantidad posible de buffers de comando. Solo es necesario dividir los buffers de comandos si necesitas que los datos se escriban de nuevo en la memoria unificada. Esto es poco frecuente.

A diferencia de los buffers de comandos, los pases no requieren sincronización con la memoria unificada. Aún consumen un ancho de banda de memoria sustancial, dependiendo del objetivo de renderizado y del tamaño del despacho de cómputo. Así que es mejor utilizar la menor cantidad posible para ahorrar ancho de banda.

Como en muchos celulares, la GPU de los dispositivos de Apple se basa en un renderizador diferido basado en mosaicos. Seguir prácticas adecuadas para combinar pases y ahorrar ancho de banda de memoria ayudará a que tu sitio o app web sobresalga en el hardware de Apple. Para obtener más información sobre los renderizadores basados en mosaicos, consulta "Optimize Metal Performance for Apple silicon Macs" y "Harness Apple GPUs with Metal" de la WWDC 2020.

Con esto en mente, enfoquémonos en los grupos de enlace. Se implementan con buffers de argumentos de Metal y crearlos también crea un nuevo MTLBuffer. Al usar desplazamientos dinámicos, se puede crear un solo grupo de enlace con el mismo diseño, pero con diferentes recursos en tiempo de ejecución. Para utilizar desplazamientos dinámicos, se debe crear un diseño de grupo de enlace personalizado y no utilizar un diseño automático desde el módulo de sombreado.

El diseño se crea llamando a createBindGroupLayout con hasDynamicOffset y luego pasando el diseño recién creado para crear el grupo de enlace. Los desplazamientos dinámicos están involucrados en las llamadas a setBindGroup. Se requiere un desplazamiento por búfer dinámico en el grupo de enlace.

En este caso, el grupo de enlace tiene un búfer que los utiliza, por lo que se pasa un desplazamiento a setBindGroup.

Por ejemplo, en lugar de crear 10 grupos de enlace con un búfer de 64 bytes en su interior, un mejor enfoque es crear un búfer de 640 bytes para representar 10 objetos de 64 bytes. Con esto, evito crear 9 buffers de Metal.

Al almacenar datos similares en menos memoria, evitar la validación repetida y minimizar la cantidad total de objetos de Metal creados, puedes crear sitios web y apps sorprendentes y eficientes con WebGPU. Ten en cuenta estas consideraciones de rendimiento al utilizar WebGPU. WebGPU permite ejecutar algoritmos personalizados directamente en la GPU, algo que antes no era posible desde la web. Te recomiendo que comiences a usar WebGPU hoy mismo en la Mac, el iPhone, el iPad y Vision Pro, y que tengas en cuenta las pautas.

Me entusiasma el futuro de la programación de GPU en la web.