WebGPU se lanza oficialmente para Windows en Firefox 141

 (mozillagfx.wordpress.com)
3 puntos por GN⁺ 2025-07-17 | 1 comentarios | Compartir por WhatsApp
  • WebGPU ya cuenta con soporte oficial en Firefox 141 para Windows tras un largo desarrollo
  • WebGPU es una interfaz web de GPU para procesamiento gráfico moderno y cómputo de alto rendimiento, y se espera que eleve de forma importante el nivel de los juegos, la visualización y el cómputo local
  • La implementación de WebGPU en Firefox está construida sobre la biblioteca WGPU basada en Rust, con soporte para varios backends como Direct3D 12, Metal y Vulkan
  • Por ahora solo se activa oficialmente en Windows, y el soporte para Mac, Linux y Android está previsto más adelante
  • Aún quedan tareas de desarrollo pendientes, como mejoras de rendimiento y cumplimiento del estándar

Qué significa el soporte de WebGPU en Windows

  • WebGPU, desarrollado durante mucho tiempo, llega oficialmente a Firefox 141 en el entorno Windows
  • WebGPU es un estándar moderno que permite que el contenido web se conecte directamente con la GPU del usuario para implementar gráficos de alto rendimiento y cómputo paralelo
  • Gracias a esta tecnología, se espera una gran expansión de los límites de rendimiento en áreas como juegos web, visualización de datos y machine learning
  • Se puede aprender y practicar con el tutorial de WebGPU, los ejemplos de WebGPU y la documentación de MDN
  • WebGPU está definido por el estándar WebGPU de W3C y el estándar WGSL, y Mozilla ha participado activamente en el proceso de estandarización desde 2017

Estado de WebGPU según el navegador

  • En Chrome, el soporte para WebGPU ya está disponible desde 2023
  • En Safari 26, su lanzamiento está previsto para este otoño
  • Firefox 141 actualmente solo tiene soporte oficial en Windows, y se ampliará a Mac/Linux/Android en futuras actualizaciones
  • En la versión Firefox Nightly, hasta ahora podía usarse de forma experimental en todas las plataformas excepto Android

Implementación de WebGPU en Firefox

  • El WebGPU de Firefox fue desarrollado sobre la biblioteca open source de Rust ** WGPU**
    • WGPU se conecta con APIs gráficas de bajo nivel como Direct3D 12, Metal y Vulkan, adaptándose al hardware de distintas plataformas
    • Mozilla es uno de los principales contribuidores del proyecto WGPU
    • Si eres desarrollador de Rust, la mejor forma de contribuir a WebGPU en Firefox es empezar por el proyecto WGPU
  • WGPU también se usa ampliamente fuera de Firefox y cuenta con una comunidad activa

Principales desafíos y trabajos de mejora

  • WebGPU es una API grande y compleja, y hasta ahora la estabilización se ha centrado en demos principales y casos de uso reales
  • Áreas que requieren mejoras adicionales:
    • Resolver la caída de rendimiento causada por el IPC sin buffering con el proceso sandbox de GPU (bug 1968122, con mejora de rendimiento prevista en Firefox 142)
    • Reducir la latencia adicional causada por detectar la finalización de tareas de GPU solo mediante un temporizador por intervalos (bug 1870699, actualmente en mejora con un método mejor)
    • La falta de soporte para importExternalTexture impide leer directamente los datos de video del decodificador hacia la GPU (bug 1827116, en desarrollo)
  • Si aparecen problemas en uso real, es necesario reportarlos en el componente WebGPU de Bugzilla adjuntando detalles completos

Planes a futuro

  • Después de Windows, se ampliará el soporte oficial a Mac, Linux y Android en ese orden
  • Hay planes de mejora continua en rendimiento, compatibilidad y cumplimiento del estándar
  • Se espera que el soporte oficial de WebGPU abra nuevas posibilidades para las aplicaciones web

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-07-17
Opiniones en Hacker News

  • Es una noticia realmente emocionante; felicidades al equipo de Firefox.
    Mi empresa está desarrollando la ejecución de Unreal en el navegador y construyó un WebGPU RHI personalizado adaptado a Unreal Engine 5.
    Quienes quieran ver una demo técnica por sí mismos pueden revisar los enlaces de abajo.
    (Solo funciona en navegadores de escritorio basados en Chromium y en algunos teléfonos Android).
    Cropout: https://play-dev.simplystream.com/?token=aa91857c-ab14-4c24-963a-36203784474b
    Configurador de autos: https://garage.cjponyparts.com/

    • Lo probé en Firefox 142 (nightly).
      Cropout se quedó mucho tiempo en 0% mientras hacía más de 1200 solicitudes de red.
      Al final carga hasta el menú, pero el fondo queda negro y solo se ven los elementos de la UI.
      Aparecieron muchos errores al parsear shaders, además de otros errores.
      El configurador de autos se queda en 0% con varios errores y no termina de cargar.
      Aparece el mensaje: "faltan archivos del juego, lo que dificulta inicializar shaders globales y contenido".
      Ojalá lo hubieran compartido después de hacer al menos pruebas mínimas también en Firefox.

    • Dijiste que "solo funciona en navegadores basados en Chromium", pero esta publicación trata justamente sobre WebGPU en Firefox,
      así que me pregunto si planean probar o lanzar una versión compatible con Firefox.

    • Probé "cropout" en Android Chrome en un Pixel 7a y se queda en 0%.
      "car configurator" avanza hasta 97~98%, pero después ya no sigue.

    • Me pregunto si funciona en Windows con Firefox 141.
      Si no, me gustaría saber por qué.

    • En Google Chrome para macOS, el primer enlace se quedó en 0% sin avanzar,
      y la segunda demo se detuvo en 98% o 97%.
      En Safari pasó lo mismo.

  • Viendo la situación actual de las APIs gráficas, siento que incluso hemos retrocedido frente a la era de OpenGL.
    Me parece que las APIs modernas no ofrecen realmente facilidad de uso ni verdadera portabilidad o multiplataforma.
    Tener que hacer wrappers personalizados para distintos backends gráficos como Vulkan, Metal y DirectX12 es casi una pérdida de tiempo.
    Se siente como volver de strings a arreglos de char solo por rendimiento.

    • No sé qué promesa había ni quién la hizo.
      El objetivo de una API gráfica siempre fue meter código y datos en la GPU lo más rápido posible, no priorizar la experiencia del desarrollador.
      Siento que WebGPU envuelve bastante bien el cómputo y el render dentro del navegador.
      Aún no es perfecto, pero me parece más intuitivo y explorable que WebGL u OpenGL.

    • No termino de ver el problema.
      En el stack gráfico siempre han existido APIs de bajo nivel desde hace mucho tiempo (por ejemplo, Gallium de Mesa), y ahora simplemente están estandarizadas y el usuario las elige directamente.
      Las APIs de alto nivel siguen existiendo, y OpenGL todavía tiene soporte en plataformas razonables.
      También he podido usar bastante bien WebGPU en código nativo.
      La falta de verdadera portabilidad en estas APIs de bajo nivel es casi completamente culpa de Apple y de los fabricantes de consolas.
      Aunque, en el caso de las consolas, nunca se esperaba mucha cooperación.

    • La lección que nos dejó la era de OpenGL es que no porque todas las plataformas usen la misma API de alto nivel necesariamente se obtienen buenos resultados.
      Al final, lo importante es si existe una API que controle bien el hardware de esa plataforma.
      Siempre se necesitaron wrappers que tradujeran OpenGL tal cual, y antes no había forma de evitarlo.
      La estrategia de exprimir el mejor resultado para cada tipo de hardware no es muy práctica.
      Lo verdaderamente importante es si se ofrece una capa de traducción fácil.
      Si de verdad quieres meterte a fondo con el hardware, entonces necesitas una API que te acerque directamente a él, no una interfaz simple o genérica.

    • OpenGL se volvió demasiado complejo después de la versión 2.0, y WebGPU envuelve de forma bastante cómoda las capacidades de Vk, D3D12 y Metal.
      Me parece mucho mejor diseñado que OpenGL.
      Aparte, D3D11 y Metalv1 probablemente sean el mejor punto medio entre usabilidad y rendimiento (sobre todo porque el rendimiento de D3D11 es difícil de alcanzar incluso con Vulkan y D3D12).

    • Yo también estoy de acuerdo.
      Voy a seguir desarrollando con interop entre OpenGL y CUDA.
      Vulkan tiene una complejidad tan sobrediseñada y tan pocas ventajas prácticas de uso que al final terminé usando CUDA.

  • Sigo esperando que WebGPU se expanda con éxito fuera del navegador
    y se convierta en una API multiplataforma fácil de usar cubierta por una especificación oficial (es decir, un reemplazo de OpenGL).
    Pero, fuera del lado de Rust, no siento que haya mucho movimiento para usar WebGPU en código nativo.
    Por ejemplo, nunca he oído de un gran proyecto que use Dawn.
    Probablemente también se deba a que WebGPU llegó demasiado tarde y la mayoría ya había construido su propia capa de abstracción sobre dx, vulkan y metal.

    • En la práctica, creo que no se va a difundir.
      Tiene algo de simplicidad, pero le faltan muchas funciones.
      Algunas funciones opcionales en Vulkan (por ejemplo, render pass) siguen siendo obligatorias en WebGPU.
      Los bind groups son estáticos y eso lo vuelve incómodo.
      Además, WebGPU tiene varias limitaciones y elementos innecesarios.
      Por ejemplo, no puedes escribir directamente desde el host a una subregión del buffer y estás obligado a usar un buffer intermedio (staging buffer).
      Como no hay alternativa, lo usaré en la web, pero en escritorio pienso seguir con un framework basado en interop OpenGL+CUDA.
      Espero que aparezca una API gráfica moderna más razonable.
      Si una tarea que debería resolverse simplemente con cuMemAlloc y cuMemcpy se vuelve compleja por asignación y binding de buffers, pipelines, sincronización explícita, binding groups, descriptor sets y otras cosas innecesarias, no quiero usarla.

    • WebGPU no ofrece el mismo nivel de optimización ni de control fino que Vulkan, y normalmente tampoco alcanza el mismo rendimiento.
      Varias extensiones disponibles en Vulkan todavía no están soportadas en WebGPU.

    • Ya existe middleware para eso.
      Fuera del navegador, no creo que haya que esperar a WebGPU.
      Después de todo, hay limitaciones derivadas de diseñar una API enfocada en el sandbox del navegador.

    • Creo que el propio nombre también fue un gran problema.
      Yo soy desarrollador puramente nativo, así que durante años simplemente ignoré el nombre "web gpu" pensando que era una tecnología solo para la web, pero al final era un malentendido.

  • Me alegra muchísimo que nuestro crate gpu-allocator https://github.com/Traverse-Research/gpu-allocator/ probablemente vaya a ser conocido por mucha más gente.
    Hasta ahora se había usado en el backend dx12 de wgpu o en nuestro propio producto de benchmarks GPU, evolve https://www.evolvebenchmark.com/.
    Espero que a partir de ahora pueda usarse de forma más amplia.

  • Recién me entero de que ya se puede usar WebGPU en Firefox Nightly para macOS.
    Bajé la nightly para Mac desde https://www.mozilla.org/en-US/firefox/channel/desktop/
    y probé la demo https://huggingface.co/spaces/reach-vb/github-issue-generator-webgpu, y funcionó bien.
    Esta demo usa el modelo SmolLM2 compilado a WebAssembly para extracción de datos estructurados.
    Antes pensaba que solo funcionaba en Chrome, pero en Firefox estable sale el error "WebGPU no está soportado".

    • Soy miembro del equipo de Firefox WebGPU.
      El soporte para macOS se ofrecerá oficialmente muy pronto.
      Además de Windows, planeamos habilitar WebGPU pronto también en Mac, Linux y, por último, Android.

  • Me alegra leer que "planean habilitar WebGPU en Mac, Linux y, por último, Android".
    Pero por ahora me cuesta entusiasmarme demasiado.
    Creo que la razón por la que el soporte de WebGPU en navegadores Linux no fue posible hasta ahora probablemente sea que es demasiado difícil crear una nueva superficie de ataque.
    Esta complejidad en sí misma demuestra lo enormes que se volvieron los estándares web, y por qué desarrollar navegadores se volvió tan difícil.
    Parece que el impacto de decisiones de diseño que vienen desde la era de Netscape sigue hasta hoy, y está en la raíz de preocupaciones como la monocultura de navegadores y los problemas de financiamiento.

    • Depende de a qué Linux te refieras.
      WebGPU ya está soportado en Android/Linux, WebOS/Linux y ChromeOS/Linux.
      Sin embargo, eso demuestra que, desde la perspectiva de los vendors de navegadores, dar soporte a estas cargas de trabajo en GNU/Linux no tiene alta prioridad.

  • También espero una implementación para Linux.
    Me pregunto si hay demos interesantes que valga la pena probar cuando llegue WebGPU.

  • Parece que Firefox va a terminar soportando WebGPU en Linux antes que Chrome.

    • La verdad, es un poco sorprendente.
      Aunque dawn (la implementación de webgpu de Google) funciona bastante bien en Linux, Firefox está terminando por adelantarse en el soporte.

  • Por fin comenzó el soporte de WebGPU, así que aplausos para todos.
    Me incomodaba un poco estar experimentando con WebGPU solo en Chrome,
    y Safari también empezó a soportarlo recientemente en versiones preview.

  • Llevo casi 2 años usando wgpu en un proyecto principal.
    Espero que con esta expansión de WebGPU aumente la cantidad de maintainers
    y que issues que abrí hace 18 meses se resuelvan más rápido.
    Aún no me he metido con Rust, pero ojalá algún día tenga la motivación y el tiempo para contribuir yo mismo.
    Dependo de bindings de wgpu-native y las actualizaciones tardan en llegar.
    Por ejemplo, la semana pasada por fin llegamos a v25, pero hace apenas unos días ya salió v26.