Descubra o poder da GPU com WebGPU

Olá! Meu nome é Mike. Sou engineer na equipe Safari. Hoje vou mostrar como a WebGPU abre as portas da computação paralela em GPUs da web. A WebGPU pode fazer tudo que a WebGL faz quando se trata de gráficos 3D, mas com melhor desempenho e mais flexibilidade. É a melhor escolha para gráficos na web. Além disso, é a única maneira de executar cálculos de uso geral na GPU diretamente no navegador. Se você já conhece o Metal, vai se sentir em casa. A maioria das chamadas é associada individualmente a chamadas do framework Metal. Ela tem suporte em todas as plataformas compatíveis com o Metal, especificamente: Mac, iPhone, iPad e Vision Pro. Sendo uma API da web, sites e apps que usam a WebGPU são executados em todos os lugares compatíveis. Em sistemas que não são da Apple, a WebGPU é implementada com APIs semelhantes ao Metal. E se você não conhece programação gráfica de baixo nível, há muitas bibliotecas de gráficos da web que você pode usar e suportam a WebGPU, dando acesso a todo o desempenho e recursos que ela oferece. Você pode usar o threeJS executado com WebGPU nos bastidores para animar em tempo real essas belas águas-vivas 3D. Esse é um exemplo maravilhoso, e ele é executado tão bem no Safari! Isso porque a WebGPU foi projetada desde o início para aproveitar ao máximo o hardware moderno de hoje. Começarei falando da API e como a WebGPU é associada ao Metal. Você vai ver muito do código necessário para qualquer app da WebGPU. Depois, vou explicar como criar programas de sombreamento da WebGPU: um código executado direto na GPU. Vou abordar a linguagem de sombreamento e por que uma nova é necessária para a web.

Depois dos fundamentos, falarei sobre como alcançar o melhor desempenho com a API. Se você já conhece a WebGPU, isso será especialmente interessante, pois abordo otimizações específicas para as plataformas da Apple. Então, vamos começar dando uma olhada no pipeline de gráficos.

Considere que o pipeline flui da esquerda para a direita. Ele começa com o site ou app da web, que carrega conteúdo, como imagens, vídeos ou dados binários.

Esse conteúdo então é passado para o WebKit, responsável por deixá-lo pronto para a GPU.

O WebKit chama o framework Metal para criar recursos e programas que mais tarde serão executados direto no hardware gráfico.

Vamos detalhar mais. Na WebGPU, o Metal gera três tipos de recursos: buffers, texturas e amostradores. Eles são organizados por WebKit em um grupo de ligação da GPU. Basicamente, é uma forma estruturada de agrupar recursos para serem usados de modo eficiente pela GPU. Internamente, eles são agrupados em um buffer de argumento: um buffer do Metal contendo referências aos recursos da GPU. Os programas em si vêm de strings de código e são compilados em três tipos principais: programas de computação, de vértice e de fragmento. Essas são as instruções executadas na GPU que fazendo tudo, desde cálculos até renderização de pixels na tela. Com sólida compreensão de como recursos e programas se encaixam no pipeline, vejamos um panorama de como a WebGPU define as diferentes interfaces em sua API.

A WebGPU é uma API simples, mas com muitas interfaces. No topo da hierarquia estão as interfaces do objeto da GPU e do GPUAdapter.

Um canvas é normalmente usado com a WebGPU. O canvas pode retornar um GPUCanvasContext consultando o contexto da WebGPU.

Um dispositivo é o principal ponto de entrada para a maioria das chamadas de API. É o que você usa para criar a maioria das outras interfaces.

Embora existam muitas interfaces na API, elas pertencem a algumas categorias simples: recursos como texturas, buffers e amostradores.

Codificadores, que emitem comandos para recursos. Pipelines, que informam como vários recursos devem ser interpretados pelos codificadores. Grupos de ligação, que agrupam recursos relacionados. E módulos de shader, que contêm instruções para executar cálculos na GPU. Agora que entendemos a estrutura geral da WebGPU, vou apresentar o trabalho com a API, mostrando como criar o dispositivo e os recursos.

O dispositivo é o ponto de entrada para a maioria das chamadas de API. Se você conhece o Metal, ele parece muito com o MTLDevice.

Supondo que você tenha uma página com um canvas, comece obtendo o elemento canvas. Depois, use navigator.gpu.requestAdapter() para criar um adaptador e chamar requestDevice para criar seu dispositivo de GPU.

A WebGPU suporta várias extensões, sendo uma delas a shader-f16, que permite usar pontos flutuantes de 16 bits.

Elas ajudam no desempenho reduzindo a largura de banda da memória. Esse recurso é compatível com todos os dispositivos Apple, mas é opcional. Então, verifique se há suporte antes de usá-lo em outras plataformas.

Depois, configure o contexto do canvas com o dispositivo chamando configure. Isso vincula o canvas à memória em que a GPU pode gravar.

Agora que o dispositivo está pronto, posso começar a criar recursos. Na WebGPU, você trabalhará muito com buffers e texturas. No Metal, eles são representados por MTLBuffer e MTLTexture.

Os buffers são superflexíveis. Use-os para armazenar todos os tipos de dados, desde os simples, como vetor de pontos flutuantes, até os mais complexos e personalizados. Por exemplo, você pode ter um buffer com várias instâncias de um tipo de partícula. Imagine, três partículas armazenadas no buffer.

Um buffer é criado chamando createBuffer no dispositivo, passando o tamanho do buffer e um modo de uso. O modo de uso permite que a WebGPU evite corridas de dados sem mais complexidades de API.

O dispositivo tem uma propriedade chamada queue, usada para executar operações em buffers e texturas.

Com o buffer criado, use writeBuffer para inserir os dados, informando o buffer, um offset e um arrayBuffer do JavaScript.

Como os buffers, texturas são blocos de memória, mas são ligadas a registradores e instruções específicas da GPU. Geralmente representam dados de imagem e podem ser unidimensionais, bidimensionais, uma matriz de texturas 2D, um cube map, que é uma matriz com seis texturas 2D, ou ainda uma textura 3D.

Você cria uma textura chamando device.createTexture e passando largura, altura e formato 2D da textura, além dos modos de uso.

Após criar a GPUTexture, podemos carregar dados de imagem com device.queue.copyExternalImageToTexture passando o bitmap da imagem, a textura 2D que criamos e o tamanho da imagem.

Uma textura geralmente é criada com dados de imagem e representa uma imagem na GPU. Depois de criar um dispositivo e recursos, vamos ver como criar um pipeline.

Um pipeline especifica como texturas e buffers serão usados na GPU. Existem dois tipos de pipelines. Pipelines de renderização, usados com programas de vértice e fragmento, e pipelines de computação, usados com programas de computação. Elas correspondem aos objetos MTLRenderPipelineState e MTLComputePipelineState do Metal.

Para criar um pipeline de computação, chame device.createComputePipeline passando um layout de grupo de ligação ou o identificador auto, que gera um layout com base o shader.

Um layout é uma forma estruturada de passar buffers, texturas e amostradores da API para o programa da GPU.

É preciso um módulo de shader para criar um pipeline. Ele é criado de uma string.

Os pipelines de renderização são criados de modo parecido, com um layout auto e módulos de shader de vértice e fragmento.

Com o dispositivo, recursos e pipelines criados, concluímos a configuração básica de qualquer app da WebGPU.

Agora que conhecemos a arquitetura da API WebGPU, vamos ver como desenvolver seus shaders.

A linguagem de sombreamento da WebGPU, a WGSL, permite que os sites escrevam programas executados direto na GPU. A Apple participa ativamente do design e da implementação da WGSL. Desde o início, a WGSL foi criada para ser segura para a web. Ela suporta três tipos de programas: programas de vértice, programas de fragmento e programas de computação.

Vou explicar como criar este exemplo simples da WebGPU, que é composto por: um programa de vértice, que recebe dados de buffer do JavaScript e cria triângulos na tela, um programa de fragmento, que calcula valores individuais de cor e profundidade de texturas e um programa de computação, que pode fazer qualquer cálculo geral, mas aqui usaremos para simular física.

O programa de vértice calcula onde os triângulos aparecem na tela.

Aqui vemos ver os contornos dos 100.000 triângulos que são usados neste exemplo.

Para escrever a posição de saída dos triângulos, use o atributo @builtin(position).

Aqui está a definição da função principal junto com as entradas do shader de vértice. Ele escreve a posição e uma cor. Agora, vamos ver um shader de fragmento.

Pegue a cor que geramos no estágio de vértice e armazene-a na textura. Este exemplo é simples, mas você pode inserir qualquer lógica para calcular valores de cor e profundidade. Você também pode escrever em texturas de armazenamento, buffers, realizar operações atômicas e muito mais. A WGSL é realmente flexível. Vamos ver agora algo ainda mais flexível: shaders de computação.

Como outros tipos de programa, shaders de computação podem conter muitas ligações, que são entradas do JavaScript em um shader.

Os shaders de computação são incríveis porque permitem fazer qualquer cálculo, armazenar os resultados em buffers e ler os buffers de volta no seu código JavaScript. Não precisa haver nenhuma visualização na tela. A WebGL não permitia shaders de computação. Essa é outra razão para usar a WebGPU para seus novos apps.

O programa de computação requer um workgroup_size, que define o tamanho da grade onde o shader de computação será executado.

Também usaremos o global_invocation_id, que é a posição em toda a grade. Esta é uma variável builtin, que pode ser usada sem a necessidade de passar nada do JavaScript.

O corpo do shader de computação atualiza a simulação de partículas, aplicando gravidade, velocidade e tempo decorrido.

Você pode fazer qualquer cálculo em um shader de computação, que é executado em paralelo com desempenho incrível na GPU.

Quando a partícula desaparece, um novo ponto é escolhido para reposicionar a partícula, chamando textureLoad em um mapa de probabilidades e selecionando uma nova posição.

Por fim, os outros atributos de partícula são redefinidos para seus valores iniciais, e a partícula é armazenada no buffer.

Se juntarmos tudo, teremos esta bela animação com o logotipo da WebGPU. Aproveitando o processamento paralelo da GPU, você pode fazer cálculos arbitrários em tamanhos antes impossíveis na web, mantendo um bom desempenho em tempo real.

É ótimo, não é?

Essa foi uma rápida visão geral de como desenvolver shaders para apps da WebGPU. Agora vou mostrar como conseguir o melhor desempenho com a WebGPU.

Algumas diretrizes simples ajudam você a oferecer a melhor experiência nas plataformas da Apple. Uma chave para ótimo desempenho é atentar ao uso da memória, e isso significa: usar tipos de dados eficientes termos de memória, gravar comandos de renderização uma vez e reutilizá-los e manter poucos recursos. Vamos ver mais detalhes.

Há algumas maneiras de minimizar o uso de memória. Primeiro, use pontos flutuantes de 16 bits. Eles são um padrão da IEEE. Em WGSL, o tipo de dados é chamado de f16. Eles ajudam mesmo a reduzir o uso de memória e melhorar o desempenho. No entanto, nem sempre são práticos. Garanta que seus algoritmos sejam estáveis com menor precisão e lembre-se: os valores máximos passam um pouco de 65.000, enquanto os pontos flutuantes de 32 bits suportam valores maiores. No iOS e no visionOS, armazenar dados em f16 ou formatos compactados pode evitar que seu programa seja encerrado por pressão de memória. Para usar pontos flutuantes de 16 bits, habilite-os durante a criação do dispositivo e no seu código WGSL. Vou mostrar como fazer isso com um exemplo de código.

Primeiro, habilite a extensão shader-f16 na chamada para requestDevice e, no shader, adicione a instrução enable f16.

Então você poderá usar tipos escalares e vetoriais de f16, com todos os tipos de 32 bits que já usava. Mesmo que você só armazene os dados em 16 bits e converta imediatamente para f32, ainda terá ganhos de memória que ajudam a evitar que seu app seja encerrado por pressão de memória.

Outra forma de minimizar o uso de memória é evitar chamadas desnecessárias de atualização de buffer e textura. Elas exigem cópias de dados do JavaScript para a memória que faz o backup do recurso do Metal. Atualizar buffers com modos de uso indireto e de índice pode ser especialmente caro, já que a validação precisa ser executada antes de usar o buffer de novo. Esses buffers são indexados direta ou indiretamente em buffers de vértice, e a WebGPU deve garantir que os offsets estejam dentro dos limites antes de executar comandos de desenho.

Só atualize esses tipos de buffer quando necessário. Isso também vale para o uso de um buffer em um grupo de ligação com acesso de gravação ou leitura/gravação. Como ilustrado no exemplo, prefira acesso somente leitura, a menos que você escreva no recurso do shader, especialmente se o recurso for um índice ou buffer indireto. Seguir essas dicas sobre memória pode ter grande impacto no desempenho, não apenas nas plataformas da Apple, mas em todos os dispositivos móveis e desktops. Agora quero falar mais sobre como reutilizar seus comandos de renderização.

Os pacotes de renderização são uma ótima forma de fazer isso, permitindo codificar comandos uma vez e reproduzi-los quantas vezes precisar. A WebGPU precisa garantir que todas as leituras e gravações estejam bem-definidas e dentro dos limites, exigindo muita validação a cada quadro. Mas com os pacotes de renderização, essa validação só acontece uma vez, quando o pacote é criado, não toda vez que é executado. Isso economiza tempo e aproxima seu app do desempenho nativo, deixando mais espaço para a lógica. E criar um pacote de renderização é bem simples. Comece criando um render bundle encoder e depois codifique suas chamadas de desenho, como faria com um render pass encoder. Chamar finish() cria o pacote para reutilização. Agora que você tem um pacote, pode executar os comandos de desenho chamando executeBundles() e repetir quantas vezes quiser.

Os pacotes de renderização correspondem aos buffers de comando indireto do Metal, com benefícios de desempenho semelhantes. Já abordamos o uso de memória e reduzimos a sobrecarga de validação, então vamos falar da redução no número de recursos:

buffers de comando, computer e render passes, grupos de ligação e layouts de grupos de ligação.

Os limites de buffer de comando exigem sincronização entre a memória rápida on-chip e a memória unificada no dispositivo. Se possível, use um buffer de comando por loop de atualização. Se não for possível, uma boa regra geral é usar o menor número de buffers de comando possível. Lembre-se: só é preciso dividir os buffers de comando quando for necessário gravar dados de volta na memória unificada. Isso ocorre raramente.

Ao contrário dos buffers de comando, os passes não exigem sincronização com a memória unificada. Eles ainda consomem muita largura de banda de memória, dependendo do destino da renderização e do tamanho do dispatch. Então use o mínimo possível para economizar largura de banda da memória.

Como muitos celulares, a GPU nos dispositivos da Apple é baseada em um renderizador diferido em blocos. Combinar passes e economizar largura de banda de memória ajuda seu site ou app a ter ótimo desempenho nos dispositivos da Apple. Saiba mais sobre renderizadores baseados em blocos em "Otimizar o desempenho do Metal em Mac com Apple Silicon" e "Otimizar as GPUs da Apple com o Metal", da WWDC 2020.

Agora vamos falar dos grupos de ligação. Elas são implementadas com buffers de argumento do Metal, então criar um grupo de ligação também cria um novo MTLBuffer. Com offsets dinâmicos, é possível usar um único grupo de ligação com o mesmo layout, mas com recursos diferentes no tempo de execução. Para usar offsets dinâmicos, é preciso criar um layout de grupo de ligação personalizado em vez de usar um layout automático do módulo de shader.

O layout é criado chamando createBindGroupLayout com hasDynamicOffset, e depois passado para criar o grupo de ligação. Os offsets dinâmicos são envolvidos em chamadas para setBindGroup. É necessário ter um offset por buffer dinâmico no grupo de ligação. Nesse caso, o grupo de ligação tem um buffer usando offsets dinâmicos. Então um offset é passado para setBindGroup.

Por exemplo, em vez de criar dez grupos de ligação, cada um com um buffer de 64 bytes, é muito melhor criar um só buffer de 640 bytes para representar dez objetos de 64 bytes. Com isso, eu evitei a criação de nove buffers do Metal.

Ao armazenar dados semelhantes com menos memória, evitar validações repetidas e minimizar a criação de objetos do Metal, você pode criar sites e apps impressionantes e muito eficientes com a WebGPU. Espero que você leve em conta essas considerações de desempenho ao usar a WebGPU. A WebGPU permite executar algoritmos personalizados diretamente na GPU, algo que antes não era possível na web. Comece a usar a WebGPU hoje mesmo no Mac, iPhone, iPad e Vision Pro, e considere as diretrizes de uso ideal.

Estou muito empolgado com o futuro da programação de GPU na web.