WebGPU chega oficialmente ao Firefox 141 para Windows

 (mozillagfx.wordpress.com)
3 pontos por GN⁺ 2025-07-17 | 1 comentários | Compartilhar no WhatsApp
  • O WebGPU passa a ter suporte oficial na versão Windows do Firefox 141 após um longo período de desenvolvimento
  • O WebGPU é uma interface de GPU baseada na web para processamento gráfico moderno e computação de alto desempenho, e deve elevar bastante o nível de jogos, visualização e processamento local
  • A implementação de WebGPU no Firefox foi construída sobre a biblioteca WGPU, baseada em Rust, com suporte a diversos backends como Direct3D 12, Metal e Vulkan
  • No momento, ele é habilitado oficialmente apenas no Windows, com suporte a Mac, Linux e Android previsto para o futuro
  • Ainda restam tarefas de desenvolvimento, como melhorias de desempenho e conformidade com o padrão

O significado do suporte ao WebGPU no Windows

  • O WebGPU, desenvolvido ao longo de muito tempo, foi oficialmente incorporado ao Firefox 141 no ambiente Windows
  • O WebGPU é um padrão moderno que permite que conteúdo web se conecte diretamente à GPU do usuário para oferecer gráficos de alto desempenho e computação paralela
  • Com essa tecnologia, espera-se uma grande expansão dos limites de desempenho em áreas como jogos baseados na web, visualização de dados e machine learning
  • É possível estudar e praticar com o tutorial de WebGPU, os exemplos de WebGPU e a documentação da MDN
  • O WebGPU é definido pelo padrão WebGPU do W3C e pelo padrão WGSL, e a Mozilla participa ativamente do processo de padronização desde 2017

Situação do WebGPU em cada navegador

  • No Chrome, o suporte a WebGPU já existe desde 2023
  • No Safari 26, o lançamento está previsto para este outono
  • O Firefox 141 atualmente oferece suporte oficial apenas no Windows, com expansão para Mac/Linux/Android planejada em atualizações futuras
  • Na versão Firefox Nightly, ele vinha podendo ser usado experimentalmente em todas as plataformas, exceto Android

Implementação do WebGPU no Firefox

  • O WebGPU do Firefox foi desenvolvido com base na biblioteca open source ** WGPU**, escrita em Rust
    • O WGPU se conecta a APIs gráficas de baixo nível como Direct3D 12, Metal e Vulkan, de acordo com o hardware de várias plataformas
    • A Mozilla é uma das principais contribuidoras do projeto WGPU
    • Para desenvolvedores Rust, a melhor forma de contribuir com o WebGPU do Firefox é começar pelo projeto WGPU
  • O WGPU também é amplamente usado fora do Firefox e conta com uma comunidade ativa

Principais desafios e trabalhos de melhoria

  • O WebGPU é uma API grande e complexa, e até agora a estabilização tem se concentrado principalmente em demos importantes e casos reais de uso
  • Áreas que ainda precisam de melhorias:
    • Resolver a queda de desempenho causada por IPC sem buffering com o processo sandbox da GPU (bug 1968122, com melhora de desempenho prevista no Firefox 142)
    • Reduzir o aumento da latência causado por detectar a conclusão de tarefas da GPU apenas com um temporizador por intervalo (bug 1870699, em aprimoramento com uma abordagem melhor)
    • Falta de suporte a importExternalTexture, o que impede a leitura direta de dados de vídeo do decodificador para a GPU (bug 1827116, em desenvolvimento)
  • Se surgirem problemas em uso real, é necessário reportá-los com detalhes no componente WebGPU do Bugzilla

Próximos passos

  • Após o Windows, o suporte oficial deve ser expandido para Mac, Linux e Android, nessa ordem
  • Há planos de melhoria contínua em desempenho, compatibilidade e conformidade com padrões
  • Espera-se que o suporte oficial ao WebGPU abra novas possibilidades para aplicações web

Leituras relacionadas

1 comentários

 
GN⁺ 2025-07-17
Comentários do Hacker News

  • Isso é realmente empolgante, parabéns à equipe do Firefox
    Minha empresa está desenvolvendo uma forma de rodar Unreal no navegador e criou um WebGPU RHI customizado para Unreal Engine 5
    Para quem quiser ver uma demo técnica por conta própria, seguem os links abaixo
    (funciona apenas em navegadores baseados em Chromium no desktop e em alguns celulares Android)
    Cropout: https://play-dev.simplystream.com/?token=aa91857c-ab14-4c24-963a-36203784474b
    Car configurator: https://garage.cjponyparts.com/

    • Testei no Firefox 142 (nightly)
      O Cropout ficou em 0% por um bom tempo, com mais de 1200 requisições de rede
      No fim, ele carrega até o menu, mas o fundo fica preto e só os elementos da UI aparecem
      Houve muitos erros ao fazer parse dos shaders, além de outros erros
      O Car configurator gera vários erros, trava em 0% e não carrega
      Aparece a mensagem "faltam arquivos do jogo, dificultando a inicialização dos shaders globais e do conteúdo"
      Espero que vocês compartilhem isso depois de pelo menos um teste básico no Firefox

    • Você disse que "funciona apenas em navegadores baseados em Chromium", mas este post é justamente sobre o WebGPU do Firefox, então
      queria saber se há planos de testar ou lançar uma versão compatível com o Firefox

    • Tentei rodar o "cropout" no Chrome para Android em um Pixel 7a e ele trava em 0%
      O "car configurator" vai até 97~98%, mas depois disso não avança mais

    • Queria saber se funciona no Windows com o Firefox 141
      Se não, gostaria de entender o motivo

    • No Google Chrome para macOS, o primeiro link travou em 0% e não saiu disso
      A segunda demo travou em 98% ou 97%
      O mesmo aconteceu no Safari

  • Quando olho para o estado atual das APIs gráficas, tenho a sensação de que até regredimos em relação à era do OpenGL
    As APIs modernas parecem não oferecer de verdade facilidade de uso, portabilidade real nem cross-platform
    Criar wrappers customizados para vários backends gráficos como Vulkan, Metal e DirectX12 é quase uma perda de tempo
    É como voltar a usar arrays de char no lugar de strings por causa de desempenho

    • Não sei que promessa existia, nem quem a fez
      O objetivo das APIs gráficas sempre foi colocar código e dados na GPU o mais rápido possível, não priorizar a experiência do desenvolvedor
      Acho que o WebGPU encapsula computação e renderização muito bem dentro do navegador
      Ainda não é perfeito, mas me parece mais intuitivo e explorável do que WebGL ou OpenGL

    • Não consigo ver muito o problema
      Há muito tempo já existem APIs de baixo nível na stack gráfica (por exemplo, o Gallium do Mesa), e agora elas foram padronizadas e o usuário pode escolhê-las diretamente
      APIs de alto nível ainda existem, e o OpenGL continua suportado em plataformas razoáveis
      Também consegui usar WebGPU de forma bastante satisfatória em código native
      A falta de portabilidade real nessas APIs de baixo nível é quase toda culpa da Apple e dos fabricantes de consoles
      Embora, no caso dos consoles, ninguém esperasse cooperação desde o início

    • A lição da era OpenGL é que usar a mesma API de alto nível em todas as plataformas não garante necessariamente um bom resultado
      No fim, o importante é existir uma API capaz de controlar bem o hardware daquela plataforma
      Sempre foi preciso um wrapper que traduzisse OpenGL, e no passado não havia como evitar esse wrapper
      A abordagem que extrai o melhor resultado para cada tipo de hardware não é muito prática
      O que realmente importa é fornecer uma camada de tradução simples
      Se você quer acesso realmente profundo ao hardware, então precisa de uma API que permita chegar direto nele, em vez de uma interface simples ou genérica demais

    • O OpenGL ficou complexo demais depois da versão 2.0, e o WebGPU encapsula os recursos de Vk, D3D12 e Metal de forma bem conveniente
      Acho que ele é muito melhor projetado que o OpenGL
      Separadamente, D3D11 e Metalv1 provavelmente são o melhor ponto de equilíbrio entre usabilidade e desempenho (especialmente o desempenho do D3D11, que é difícil de alcançar até em Vulkan e D3D12)

    • Eu também concordo
      Vou continuar desenvolvendo com interoperabilidade entre OpenGL e CUDA
      O Vulkan tem uma complexidade exagerada e overengineered sem trazer vantagens práticas reais, então acabei recorrendo ao CUDA

  • Ainda espero que o WebGPU consiga se expandir com sucesso para fora do navegador
    e se torne uma API cross-platform fácil de usar tratada pela especificação oficial (ou seja, um substituto para o OpenGL)
    Mas, fora do ecossistema Rust, não sinto que haja muito movimento para usar WebGPU em código native
    Por exemplo, nunca ouvi falar de grandes projetos usando Dawn
    Provavelmente também porque o WebGPU chegou tarde demais e a maioria já tinha construído sua própria camada de abstração sobre dx, vulkan e metal

    • No fim, acho que ele não vai se espalhar
      Há um pouco de simplicidade, mas faltam muitos recursos
      Alguns recursos que são opcionais no Vulkan (como render passes) ainda são obrigatórios no WebGPU
      Os bind groups são estáticos, o que torna tudo mais incômodo
      E o WebGPU também tem várias limitações e elementos desnecessários
      Por exemplo, não dá para escrever diretamente em sub-regiões de buffer a partir do host; é obrigatório usar um buffer intermediário (staging buffer)
      Como não há alternativa, eu o usaria na web, mas no desktop vou continuar com um framework baseado em interoperabilidade entre OpenGL e CUDA
      Espero que surja uma API gráfica moderna mais sensata
      Se algo que poderia ser resolvido só com cuMemAlloc e cuMemcpy se torna complicado por causa de alocação e binding complexos de buffers, pipelines, sincronização explícita, binding groups, descriptor sets e outros elementos inúteis, então não quero usar isso

    • O WebGPU não oferece o mesmo nível de otimização e controle fino que o Vulkan, e em geral também não entrega o mesmo desempenho
      Além disso, várias extensões existentes no Vulkan ainda não são suportadas no WebGPU

    • Já existe middleware para isso
      Fora do navegador, não acho que faça sentido esperar pelo WebGPU
      Afinal, há limitações inerentes a um design de API focado originalmente no sandbox do navegador

    • Acho que o próprio nome também foi um grande problema
      Sou um desenvolvedor puramente native, então por anos tratei o nome "web gpu" como uma tecnologia exclusiva da web e nem dei atenção, mas pelo visto foi um mal-entendido

  • Estou muito feliz que nosso crate gpu-allocator https://github.com/Traverse-Research/gpu-allocator/ provavelmente vai ficar conhecido por muito mais gente
    Até agora ele vinha sendo usado no backend dx12 do wgpu e no nosso próprio produto de benchmark de GPU, o evolve https://www.evolvebenchmark.com/
    Espero que daqui para frente ele possa ser usado de forma mais ampla

  • Só agora descobri que já é possível usar WebGPU no Firefox Nightly para macOS
    Baixei o nightly para Mac em https://www.mozilla.org/en-US/firefox/channel/desktop/
    e rodei a demo https://huggingface.co/spaces/reach-vb/github-issue-generator-webgpu, e funcionou bem
    Essa demo compila o modelo SmolLM2 para WebAssembly e o usa para extração de dados estruturados
    Eu achava que isso só funcionava no Chrome, mas no Firefox estável aparece o erro "WebGPU não é suportado"

    • Sou membro da equipe de WebGPU do Firefox
      O suporte ao macOS será disponibilizado oficialmente em breve
      Além do Windows, também temos planos de suportar WebGPU em breve no Mac, Linux e, por último, no Android

  • Fico feliz em ver a parte "há planos de suportar WebGPU no Mac, Linux e, por último, no Android"
    Mas, neste momento, ainda é difícil ficar muito otimista
    Acho que o motivo de o suporte a WebGPU ter sido inviável até agora em navegadores Linux é que criar uma nova superfície de ataque é complicado demais
    Esse nível de complexidade mostra como os padrões web se tornaram enormes e como isso dificulta o desenvolvimento de navegadores
    Parece que os efeitos de decisões de design que vêm desde a era Netscape ainda persistem e estão na raiz de preocupações como a homogeneização dos navegadores e os problemas de financiamento

    • Depende de qual Linux estamos falando
      Android/Linux, WebOS/Linux e ChromeOS/Linux já suportam WebGPU
      Isso apenas mostra que, na visão dos fabricantes de navegadores, suporte para esse tipo de carga de trabalho em GNU/Linux tem prioridade baixa

  • Também estou esperando uma implementação para Linux
    Queria saber se existem demos interessantes para experimentar quando o WebGPU chegar

  • Parece que o Firefox vai acabar oferecendo suporte a WebGPU no Linux antes do Chrome

    • Na verdade, isso é meio surpreendente
      O dawn (implementação de WebGPU do Google) funciona bem no Linux, mas mesmo assim o Firefox está saindo na frente no suporte

  • Finalmente o suporte a WebGPU está começando, parabéns a todos
    Eu me sentia um pouco desconfortável por só poder experimentar WebGPU no Chrome
    E o Safari também começou a oferecer suporte em versões preview recentes

  • Já faz quase 2 anos que uso wgpu em um projeto principal
    Espero que essa expansão do WebGPU traga mais mantenedores
    e que issues abertas há 18 meses sejam resolvidas mais rapidamente
    Ainda não mexi com Rust, mas espero algum dia ter tempo e motivação para contribuir diretamente
    Dependo das bindings de wgpu-native, e as atualizações chegam devagar
    Por exemplo, só na semana passada chegou a v25, enquanto a v26 saiu há apenas alguns dias