Lancement officiel de WebGPU pour Windows dans Firefox 141

 (mozillagfx.wordpress.com)
3 points par GN⁺ 2025-07-17 | 1 commentaires | Partager sur WhatsApp
  • WebGPU est officiellement pris en charge dans la version Windows de Firefox 141 après une longue période de développement
  • WebGPU est une interface GPU basée sur le web destinée au traitement graphique moderne et au calcul haute performance, et devrait nettement élever le niveau des jeux, de la visualisation et du calcul local
  • L’implémentation de WebGPU dans Firefox est construite sur la bibliothèque WGPU basée sur Rust, avec la prise en charge de plusieurs backends comme Direct3D 12, Metal et Vulkan
  • Pour l’instant, l’activation officielle ne concerne que Windows ; la prise en charge de Mac, Linux et Android est prévue par la suite
  • Des travaux supplémentaires restent encore à mener, notamment sur les performances et la conformité au standard

Ce que signifie la prise en charge de WebGPU sur Windows

  • Développé pendant de longues années, WebGPU est désormais intégré officiellement à Firefox 141 dans l’environnement Windows
  • WebGPU est un standard moderne qui permet aux contenus web d’interagir directement avec le GPU de l’utilisateur afin d’offrir des graphiques haute performance et du calcul parallèle
  • Cette technologie devrait considérablement repousser les limites de performance dans des domaines variés comme les jeux web, la visualisation de données et le machine learning
  • Il est possible d’apprendre et de s’exercer via le tutoriel WebGPU, les exemples WebGPU et la documentation MDN
  • WebGPU est défini par le standard WebGPU du W3C et le standard WGSL ; Mozilla participe activement au processus de standardisation depuis 2017

État de WebGPU selon les navigateurs

  • Dans Chrome, la prise en charge de WebGPU existe déjà depuis 2023
  • Dans Safari 26, la sortie est prévue cet automne
  • Firefox 141 ne prend officiellement en charge que Windows pour le moment, avec une extension prévue à Mac/Linux/Android dans de futures mises à jour
  • Dans la version Firefox Nightly, il était jusqu’à présent possible d’utiliser WebGPU à titre expérimental sur toutes les plateformes sauf Android

Implémentation de WebGPU dans Firefox

  • Le WebGPU de Firefox a été développé sur la base de la bibliothèque open source Rust WGPU
    • WGPU se connecte à des API graphiques bas niveau comme Direct3D 12, Metal et Vulkan, adaptées au matériel de différentes plateformes
    • Mozilla est l’un des principaux contributeurs au projet WGPU
    • Pour les développeurs Rust, la meilleure porte d’entrée pour contribuer au WebGPU de Firefox est de commencer par le projet WGPU
  • WGPU est aussi largement utilisé en dehors de Firefox et bénéficie d’une communauté active

Principaux défis et travaux d’amélioration

  • WebGPU est une API vaste et complexe ; jusqu’à présent, la stabilisation s’est concentrée sur les principales démos et les cas d’usage réels
  • Domaines nécessitant des améliorations supplémentaires :
    • Résoudre la baisse de performances causée par l’IPC non bufferisé avec le processus sandbox GPU (bug 1968122, amélioration des performances prévue dans Firefox 142)
    • La détection de la fin des tâches GPU uniquement via un timer à intervalle augmente la latence d’attente (bug 1870699, une meilleure approche est en cours de développement)
    • L’absence de prise en charge de importExternalTexture empêche la lecture directe des données vidéo du décodeur vers le GPU (bug 1827116, développement en cours)
  • En cas de problème en usage réel, il est nécessaire de le signaler en joignant des détails dans le composant WebGPU de Bugzilla

Suite du programme

  • Après Windows, la prise en charge officielle sera étendue à Mac, Linux puis Android
  • Des améliorations continues sont prévues en matière de performances, de compatibilité et de conformité au standard
  • La prise en charge officielle de WebGPU devrait ouvrir de nouvelles possibilités pour les applications web

À lire aussi

1 commentaires

 
GN⁺ 2025-07-17
Avis Hacker News

  • C’est une nouvelle vraiment enthousiasmante, félicitations à l’équipe Firefox
    Mon entreprise travaille à faire tourner Unreal dans le navigateur, et nous avons construit un RHI WebGPU personnalisé adapté à Unreal Engine 5
    Pour ceux qui veulent voir une démo technique par eux-mêmes, voir les liens ci-dessous
    (cela ne fonctionne que sur les navigateurs de bureau basés sur Chromium et sur certains téléphones Android)
    Cropout : https://play-dev.simplystream.com/?token=aa91857c-ab14-4c24-963a-36203784474b
    Configurateur auto : https://garage.cjponyparts.com/

    • Testé sur Firefox 142 (nightly)
      Cropout est resté longtemps bloqué à 0 % avec plus de 1 200 requêtes réseau
      Au final, ça charge jusqu’au menu, mais l’arrière-plan est noir et seuls les éléments d’interface sont visibles
      Il y avait beaucoup d’erreurs lors de l’analyse des shaders, ainsi que d’autres erreurs diverses
      Le configurateur auto affiche plusieurs erreurs, reste bloqué à 0 % et ne charge pas
      Un message indique : « fichiers du jeu manquants, impossible d’initialiser les shaders globaux et le contenu »
      J’aurais aimé que ce soit partagé après au moins un minimum de tests sur Firefox aussi

    • Il est indiqué que cela « ne fonctionne que sur les navigateurs basés sur Chromium », mais comme ce post parle précisément du WebGPU de Firefox,
      je me demande si vous prévoyez de tester ou de publier une version compatible avec Firefox

    • En lançant « cropout » sur Chrome Android sur un Pixel 7a, ça reste bloqué à 0 %
      Le « configurateur auto » progresse jusqu’à 97–98 %, mais n’avance plus ensuite

    • Je me demande si cela fonctionne sur Windows avec Firefox 141
      Sinon, j’aimerais savoir pourquoi

    • Sur Google Chrome pour macOS, le premier lien est resté bloqué à 0 % sans bouger,
      et la deuxième démo s’est arrêtée à 98 % ou 97 %
      Le même phénomène s’est produit aussi sur Safari

  • En voyant l’état actuel des API graphiques, j’ai presque l’impression qu’on a régressé par rapport à l’époque d’OpenGL
    J’ai l’impression que les API modernes n’apportent ni vraie simplicité d’usage, ni véritable portabilité, ni vrai cross-platform
    Construire des wrappers personnalisés pour différents backends graphiques comme Vulkan, Metal ou DirectX12 ressemble plutôt à une perte de temps
    Ça donne un peu l’impression de revenir aux tableaux de char à la place des chaînes pour gagner en performance

    • Je ne sais pas quelle promesse a été faite, ni par qui
      Le but d’une API graphique a toujours été avant tout d’envoyer du code et des données au GPU aussi vite que possible, pas de privilégier l’expérience développeur
      Je trouve que WebGPU encapsule plutôt bien le calcul et le rendu dans le navigateur
      Ce n’est pas encore parfait, mais à mon avis c’est plus intuitif et plus facile à explorer que WebGL ou OpenGL

    • Je ne vois pas vraiment le problème
      Il existe depuis longtemps des API bas niveau dans la pile graphique (par exemple Gallium dans Mesa), et maintenant elles sont standardisées et choisies directement par les utilisateurs
      Les API haut niveau existent toujours, et OpenGL reste pris en charge sur des plateformes raisonnables
      WebGPU était aussi tout à fait utilisable en code natif
      Le vrai manque de portabilité de ces API bas niveau est presque entièrement dû à Apple et aux fabricants de consoles
      Cela dit, on n’attendait de toute façon pas vraiment de coopération de la part des fabricants de consoles

    • La leçon tirée de l’ère OpenGL, c’est que le fait que toutes les plateformes utilisent la même API haut niveau ne garantit pas forcément de bons résultats
      Au final, ce qui compte, c’est d’avoir une API qui contrôle bien le matériel de la plateforme concernée
      Il a toujours fallu des wrappers qui traduisent OpenGL tel quel, et autrefois il n’y avait aucun moyen d’y échapper
      Chercher la meilleure solution pour chaque type de matériel est peu pratique
      Ce qui compte vraiment, c’est de fournir une couche de traduction facile
      Si on veut vraiment aller en profondeur au niveau matériel, il faut au contraire une API qui permette d’y accéder directement, plutôt qu’une interface simple ou générique

    • OpenGL est devenu beaucoup trop complexe après la version 2.0, et WebGPU encapsule les fonctionnalités de Vk, D3D12 et Metal de manière plutôt pratique
      Je pense que c’est bien mieux conçu qu’OpenGL
      À part cela, D3D11 et Metalv1 sont probablement le meilleur équilibre entre ergonomie et performance (surtout les performances de D3D11, que Vulkan et D3D12 ont du mal à égaler)

    • Je suis d’accord moi aussi
      Je vais continuer à développer avec l’interop OpenGL et CUDA
      Vulkan a une complexité tellement suringénierée pour si peu d’avantages concrets à l’usage que j’ai fini par préférer CUDA

  • J’espère toujours que WebGPU s’étendra avec succès au-delà du navigateur
    et devienne une API cross-platform facile à utiliser traitée dans la spécification officielle (autrement dit, un remplaçant d’OpenGL)
    Mais en dehors de l’écosystème Rust, je n’ai pas l’impression qu’il y ait un grand mouvement vers l’usage de WebGPU en code natif
    Par exemple, je n’ai jamais entendu parler d’un gros projet utilisant Dawn
    C’est sans doute aussi parce que WebGPU est arrivé trop tard, et que la plupart avaient déjà construit leur propre couche d’abstraction au-dessus de dx, vulkan et metal

    • Au final, je pense que ça ne se diffusera pas
      Il y a un peu de simplicité, mais beaucoup trop de fonctions manquent
      Certaines fonctions devenues optionnelles dans Vulkan (comme les render passes) restent obligatoires dans WebGPU
      Les bind groups sont statiques, ce qui est au contraire peu pratique
      Et WebGPU a aussi de nombreuses limitations et des éléments inutiles
      Par exemple, on ne peut pas écrire directement dans une sous-région de buffer depuis l’hôte, il faut obligatoirement passer par un buffer intermédiaire (staging buffer)
      Faute d’alternative, je l’utiliserai sur le web, mais sur desktop je vais continuer avec un framework OpenGL + interop CUDA
      J’espère qu’une API graphique moderne plus raisonnable verra le jour
      Si une tâche qui pourrait se limiter à cuMemAlloc et cuMemcpy devient compliquée à cause d’allocations et de bindings de buffers complexes, de pipelines, de synchronisation explicite, de binding groups, de descriptor sets et d’autres éléments inutiles, je n’ai pas envie de l’utiliser

    • WebGPU n’offre ni le niveau d’optimisation ni le contrôle fin de Vulkan, et les performances ne sont généralement pas au niveau de Vulkan
      Les diverses extensions présentes dans Vulkan ne sont pas encore prises en charge dans WebGPU non plus

    • Il existe déjà des middlewares pour cela
      En dehors du navigateur, je ne pense pas qu’il soit nécessaire d’attendre WebGPU
      À l’origine, il y a les contraintes d’un design d’API centré sur la sandbox du navigateur

    • Le nom lui-même a aussi été un gros problème à mon avis
      Je suis un développeur purement natif, donc pendant des années j’ai simplement considéré « web gpu » comme une technologie réservée au web et je n’y ai pas prêté attention, alors qu’en réalité c’était une erreur

  • Je suis très heureux à l’idée que notre crate gpu-allocator https://github.com/Traverse-Research/gpu-allocator/ soit connue par bien plus de monde
    Jusqu’à présent, nous l’utilisions dans le backend dx12 de wgpu ou dans notre propre produit de benchmark GPU evolve https://www.evolvebenchmark.com/
    J’espère qu’elle pourra désormais être utilisée plus largement

  • Je découvre seulement maintenant que WebGPU était déjà utilisable dans Firefox Nightly sur macOS
    J’ai téléchargé la nightly mac depuis https://www.mozilla.org/en-US/firefox/channel/desktop/
    et j’ai lancé la démo https://huggingface.co/spaces/reach-vb/github-issue-generator-webgpu, qui a bien fonctionné
    Cette démo compile le modèle SmolLM2 en WebAssembly pour l’utiliser dans l’extraction de données structurées
    Jusqu’ici, je pensais que cela ne fonctionnait que dans Chrome, mais sur Firefox stable j’obtiens une erreur disant que « WebGPU n’est pas pris en charge »

    • Je fais partie de l’équipe WebGPU de Firefox
      La prise en charge de macOS arrivera officiellement bientôt
      En plus de Windows, nous prévoyons aussi de prendre en charge bientôt Mac, Linux, et enfin Android pour WebGPU

  • Le passage disant « nous prévoyons aussi de prendre en charge Mac, Linux, et enfin Android pour WebGPU » me fait plaisir
    Mais à ce stade, j’ai du mal à avoir de grands espoirs
    Si la prise en charge de WebGPU dans les navigateurs Linux a été impossible jusqu’ici, c’est probablement parce qu’il est trop difficile d’ajouter une nouvelle surface d’attaque
    Ce genre de complexité montre à quel point l’énormité des standards du web rend le développement des navigateurs difficile
    L’impact de décisions de conception remontant à l’époque de Netscape est encore visible aujourd’hui, et semble être à la racine des inquiétudes autour de l’uniformisation des navigateurs, du financement, etc.

    • Cela dépend de quel Linux on parle
      WebGPU est déjà pris en charge sur Android/Linux, WebOS/Linux et ChromeOS/Linux
      Mais cela montre bien que, pour les navigateurs, la prise en charge de ce type de charge de travail sur GNU/Linux reste une priorité faible pour les éditeurs

  • J’attends aussi une implémentation pour Linux
    Je me demande quelles démos il y aura à essayer quand WebGPU arrivera

  • On dirait que Firefox va prendre en charge WebGPU sur Linux avant Chrome

    • C’est en fait assez surprenant
      alors que dawn (l’implémentation WebGPU de Google) fonctionne plutôt bien sur Linux, Firefox semble tout de même passer devant sur ce support

  • Bravo à tout le monde, le support de WebGPU arrive enfin
    J’étais un peu mal à l’aise à l’idée d’expérimenter avec WebGPU uniquement dans Chrome
    Safari a lui aussi commencé à le prendre en charge récemment dans ses versions preview

  • J’utilise wgpu dans un projet majeur depuis presque deux ans
    Avec cette extension de WebGPU, j’espère qu’il y aura plus de mainteneurs
    et que les tickets que j’ai ouverts il y a 18 mois seront résolus plus vite
    Je n’ai pas encore touché à Rust, mais j’espère avoir un jour la motivation et le temps de contribuer moi-même
    Je dépends des bindings wgpu-native, mais les mises à jour y arrivent lentement
    Par exemple, on est enfin passé à la v25 la semaine dernière, alors que la v26 est sortie il y a seulement quelques jours