WebGPU für Windows in Firefox 141 offiziell veröffentlicht

 (mozillagfx.wordpress.com)
3 Punkte von GN⁺ 2025-07-17 | 1 Kommentare | Auf WhatsApp teilen
  • WebGPU wird nach langer Entwicklungszeit in der Windows-Version von Firefox 141 offiziell unterstützt
  • WebGPU ist eine webbasierte GPU-Schnittstelle für moderne Grafikverarbeitung und Hochleistungsrechnen und dürfte das Niveau von Spielen, Visualisierung und lokalen Berechnungen deutlich anheben
  • Die WebGPU-Implementierung von Firefox basiert auf der Rust-basierten Bibliothek WGPU und unterstützt verschiedene Backends wie Direct3D 12, Metal und Vulkan
  • Derzeit ist sie nur unter Windows offiziell aktiviert; Unterstützung für Mac, Linux und Android ist ebenfalls geplant
  • Zusätzliche Entwicklungsaufgaben wie Leistungsverbesserungen und Standardkonformität stehen noch aus

Bedeutung der WebGPU-Unterstützung unter Windows

  • Die über lange Zeit entwickelte WebGPU wird in Firefox 141 offiziell für Windows ausgeliefert
  • WebGPU ist ein moderner Standard, der Webinhalten die direkte Anbindung an die GPU des Nutzers ermöglicht, um leistungsfähige Grafik und parallele Berechnungen umzusetzen
  • Dadurch dürften sich die Leistungsgrenzen in Bereichen wie webbasierten Spielen, Datenvisualisierung und Machine Learning deutlich erweitern
  • Über das WebGPU-Tutorial, WebGPU-Beispiele und die MDN-Dokumentation sind Lernen und praktische Erprobung möglich
  • WebGPU ist im WebGPU-W3C-Standard und im WGSL-Standard definiert; Mozilla beteiligt sich seit 2017 aktiv am Standardisierungsprozess

WebGPU-Status nach Browser

  • In Chrome wird WebGPU bereits seit 2023 unterstützt
  • Safari 26 soll im Herbst dieses Jahres erscheinen
  • Firefox 141 unterstützt derzeit offiziell nur Windows; Mac/Linux/Android sollen mit künftigen Updates folgen
  • In der Firefox Nightly-Version war die Nutzung bisher experimentell auf allen Plattformen außer Android möglich

Die WebGPU-Implementierung von Firefox

  • Die WebGPU-Implementierung von Firefox wurde auf Basis der Open-Source-Rust-Bibliothek WGPU entwickelt
    • WGPU verbindet sich je nach Plattformhardware mit Low-Level-Grafik-APIs wie Direct3D 12, Metal und Vulkan
    • Mozilla ist ein wichtiger Beitragsleister des WGPU-Projekts
    • Für Rust-Entwickler, die zu Firefox WebGPU beitragen möchten, ist der Einstieg über das WGPU-Projekt sinnvoll
  • WGPU wird auch außerhalb von Firefox breit eingesetzt und verfügt über eine aktive Community

Wichtige Aufgaben und Verbesserungen

  • WebGPU ist eine große und komplexe API; bisher lag der Schwerpunkt der Stabilisierung auf wichtigen Demos und praktischen Einsatzfällen
  • Bereiche mit weiterem Verbesserungsbedarf:
    • Behebung von Leistungsproblemen durch ungepufferte IPC mit dem GPU-Sandbox-Prozess (Bug 1968122, Leistungsverbesserungen in Firefox 142 geplant)
    • Höhere Wartezeiten, weil die Fertigstellung von GPU-Arbeiten nur per Intervall-Timer erkannt wird (Bug 1870699, Verbesserungen mit einer besseren Methode in Arbeit)
    • Keine Unterstützung für importExternalTexture, wodurch Videodaten nicht direkt vom Decoder zur GPU gelesen werden können (Bug 1827116, Entwicklung läuft)
  • Wenn bei realer Nutzung Probleme auftreten, sollten diese mit detaillierten Angaben in der WebGPU-Komponente von Bugzilla gemeldet werden

Die nächsten Schritte

  • Nach Windows soll die offizielle Unterstützung in der Reihenfolge Mac, Linux und Android erweitert werden
  • Kontinuierliche Verbesserungen bei Leistung, Kompatibilität und Standardkonformität sind geplant
  • Mit der offiziellen Unterstützung von WebGPU dürften sich neue Möglichkeiten für Webanwendungen eröffnen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-07-17
Hacker-News-Kommentare

  • Das sind wirklich spannende Neuigkeiten, Glückwunsch an das Firefox-Team.
    Mein Unternehmen arbeitet daran, Unreal im Browser auszuführen, und wir haben ein angepasstes WebGPU-RHI für Unreal Engine 5 gebaut.
    Wer sich die Tech-Demo selbst ansehen möchte, findet unten die Links.
    (Funktioniert nur in Chromium-basierten Browsern auf dem Desktop und auf einigen Android-Smartphones.)
    Cropout: https://play-dev.simplystream.com/?token=aa91857c-ab14-4c24-963a-36203784474b
    Car configurator: https://garage.cjponyparts.com/

    • Ich habe es in Firefox 142 (nightly) getestet.
      Cropout blieb lange bei 0 %, während mehr als 1200 Netzwerkanfragen liefen.
      Am Ende lädt zwar das Menü, aber der Hintergrund bleibt schwarz und nur die UI-Elemente sind sichtbar.
      Beim Parsen der Shader traten viele Fehler auf, dazu noch diverse andere.
      Der Car configurator bleibt bei 0 % stehen, wirft mehrere Fehler und lädt nicht.
      Es erscheint die Meldung, dass Spiel-Dateien fehlen und globale Shader sowie Inhalte deshalb nicht initialisiert werden können.
      Ich hätte mir gewünscht, dass das zumindest kurz in Firefox getestet wird, bevor man es teilt.

    • Es wurde zwar gesagt, dass es nur in Chromium-basierten Browsern funktioniert, aber da es in diesem Beitrag genau um WebGPU in Firefox geht,
      würde mich interessieren, ob ihr plant, eine Firefox-kompatible Version zu testen oder zu veröffentlichen.

    • Ich habe „cropout“ auf einem Pixel 7a mit Android Chrome ausprobiert, dort bleibt es bei 0 % stehen.
      Der „car configurator“ kommt auf 97–98 %, geht danach aber nicht mehr weiter.

    • Mich würde interessieren, ob es unter Windows mit Firefox 141 funktioniert.
      Falls nicht, würde ich gern wissen, warum.

    • Unter Google Chrome auf macOS blieb der erste Link bei 0 % stehen und bewegte sich nicht weiter.
      Die zweite Demo blieb bei 98 % oder 97 % hängen.
      In Safari trat dasselbe Verhalten auf.

  • Wenn man sich den aktuellen Zustand der Grafik-APIs ansieht, wirkt es fast wie ein Rückschritt gegenüber der OpenGL-Ära.
    Moderne APIs bieten aus meiner Sicht weder eine einfache Benutzung noch echte Portabilität oder plattformübergreifende Nutzbarkeit.
    Eigene Wrapper für verschiedene Grafik-Backends wie Vulkan, Metal und DirectX12 zu bauen, ist eher Zeitverschwendung.
    Es fühlt sich an, als würde man aus Performance-Gründen wieder von Strings auf char-Arrays zurückgehen.

    • Ich weiß nicht, welches Versprechen da gemacht wurde oder wer es gemacht hat.
      Der Zweck von Grafik-APIs war immer, Code und Daten möglichst schnell auf die GPU zu bringen, nicht in erster Linie eine gute Developer Experience zu liefern.
      WebGPU kapselt Compute und Rendering im Browser meiner Meinung nach ziemlich gut.
      Noch nicht perfekt, aber ich finde es intuitiver und leichter zu erkunden als WebGL oder OpenGL.

    • Ich kann das Problem nicht so recht nachvollziehen.
      Im Grafik-Stack gibt es schon lange Low-Level-APIs (zum Beispiel Mesa Gallium), und jetzt sind sie eben standardisiert und werden vom Nutzer direkt gewählt.
      High-Level-APIs existieren weiterhin, und OpenGL wird auf vernünftigen Plattformen nach wie vor unterstützt.
      WebGPU ließ sich auch in nativem Code ganz gut verwenden.
      Das Fehlen echter Portabilität bei solchen Low-Level-APIs liegt fast ausschließlich an Apple und den Konsolenherstellern.
      Bei Konsolenherstellern hat man allerdings ohnehin nie mit Kooperation gerechnet.

    • Die Lehre aus der OpenGL-Zeit ist, dass nicht automatisch gute Ergebnisse herauskommen, nur weil alle Plattformen dieselbe High-Level-API verwenden.
      Entscheidend ist letztlich, ob es eine API gibt, die die Hardwarekontrolle der jeweiligen Plattform gut abbildet.
      Ein Wrapper, der OpenGL einfach nur übersetzt, war immer nötig, und früher gab es keine Möglichkeit, diesen Wrapper zu vermeiden.
      Der Ansatz, für jeden Hardwaretyp den jeweils optimalen Weg zu gehen, ist in der Praxis wenig sinnvoll.
      Wirklich wichtig ist, ob es eine einfache Übersetzungsschicht gibt.
      Wenn man wirklich tief an die Hardware heranwill, braucht man eher eine API, die direkten Zugang ermöglicht, statt eines einfachen oder generischen Interfaces.

    • OpenGL ist seit 2.0 als API viel zu komplex geworden, und WebGPU kapselt die Features von Vk, D3D12 und Metal ziemlich bequem.
      Ich halte es für deutlich besser entworfen als OpenGL.
      Zusätzlich sind D3D11 und Metalv1 wahrscheinlich der beste Kompromiss aus Benutzbarkeit und Performance (vor allem die Performance von D3D11 ist selbst mit Vulkan und D3D12 schwer zu erreichen).

    • Ich stimme ebenfalls zu.
      Ich werde weiter mit OpenGL- und CUDA-Interop entwickeln.
      Vulkan hat für mich so viel überengineerte Komplexität und so wenig praktischen Nutzen, dass ich am Ende lieber CUDA verwende.

  • Ich hoffe immer noch, dass sich WebGPU erfolgreich über die Browser hinaus ausweitet
    und zu einer einfach nutzbaren, plattformübergreifenden API wird, die in der offiziellen Spezifikation abgedeckt ist, also zu einem Ersatz für opengl.
    Abgesehen vom Rust-Umfeld scheint der Trend zu nativer Nutzung von WebGPU aber nicht besonders groß zu sein.
    Ich habe zum Beispiel noch nie von einem großen Projekt gehört, das Dawn verwendet.
    Vermutlich liegt das auch daran, dass WebGPU zu spät gekommen ist und die meisten bereits eigene Abstraktionsschichten über dx, vulkan und metal gebaut hatten.

    • Ich glaube letztlich nicht, dass es sich durchsetzen wird.
      Es ist zwar etwas einfacher, aber ihm fehlen auch viele Funktionen.
      Einige Dinge, die in Vulkan optional sind, sind in WebGPU weiterhin Pflicht, etwa Render Passes.
      Bind Groups sind statisch und dadurch eher unpraktisch.
      Außerdem hat WebGPU viele Einschränkungen und unnötige Elemente.
      Zum Beispiel kann man auf dem Host nicht direkt in Buffer-Subregionen schreiben und muss immer einen Zwischen-Buffer (Staging-Buffer) verwenden.
      Im Web werde ich es mangels Alternativen nutzen, aber auf dem Desktop bleibe ich bei einem OpenGL+CUDA-Interop-Framework.
      Ich hoffe auf eine modernere und vernünftigere Grafik-API.
      Wenn etwas, das mit cuMemAlloc und cuMemcpy erledigt wäre, stattdessen durch komplexe Buffer-Allokation und -Bindung, Pipelines, explizite Synchronisierung, Bind Groups, Descriptor Sets und andere unnötige Konstrukte verkompliziert wird, dann möchte ich es nicht verwenden.

    • WebGPU bietet nicht das Maß an Optimierung und feingranularer Kontrolle wie Vulkan, und meist auch nicht dessen Performance.
      Die vielen Extensions von Vulkan werden in WebGPU bislang ebenfalls nicht unterstützt.

    • Es gibt bereits existierende Middleware.
      Außerhalb des Browsers muss man aus meiner Sicht nicht extra auf WebGPU warten.
      Das liegt an den Einschränkungen, die aus einem API-Design entstehen, das ursprünglich auf die Browser-Sandbox ausgerichtet ist.

    • Schon der Name war meiner Meinung nach ein großes Problem.
      Ich bin reiner Native-Entwickler und habe „web gpu“ jahrelang einfach als reine Web-Technologie abgetan und ignoriert, aber wie sich herausstellte, war das ein Missverständnis.

  • Ich freue mich sehr, dass unser gpu-allocator-https://github.com/Traverse-Research/gpu-allocator/-Crate nun wahrscheinlich viel mehr Menschen bekannt wird.
    Bisher wurde es im dx12-Backend von wgpu oder in unserem eigenen GPU-Benchmark-Produkt evolve https://www.evolvebenchmark.com/ verwendet.
    Ich hoffe, dass es künftig noch breiter eingesetzt werden kann.

  • Mir ist erst jetzt klar geworden, dass man WebGPU in Firefox Nightly für macOS bereits nutzen kann.
    Ich habe mir die Nightly für Mac von https://www.mozilla.org/en-US/firefox/channel/desktop/ heruntergeladen
    und die Demo https://huggingface.co/spaces/reach-vb/github-issue-generator-webgpu ausprobiert; sie lief gut.
    Diese Demo kompiliert das SmolLM2-Modell nach WebAssembly und verwendet es zur Extraktion strukturierter Daten.
    Ich dachte bisher, das funktioniere nur in Chrome, aber im regulären Firefox (Stable) erscheint der Fehler, dass WebGPU nicht unterstützt wird.

    • Ich bin Mitglied im Firefox-WebGPU-Team.
      Die Unterstützung für macOS werden wir bald offiziell bereitstellen.
      Neben Windows planen wir, WebGPU bald auch auf Mac, Linux und zuletzt auf Android zu unterstützen.

  • Ich freue mich über die Aussage, dass WebGPU auch auf Mac, Linux und zuletzt auf Android unterstützt werden soll.
    Im Moment fällt es mir aber schwer, große Erwartungen zu haben.
    Dass WebGPU in Linux-Browsern bislang nicht unterstützt wurde, liegt meiner Meinung nach vermutlich daran, dass neue Angriffsvektoren einfach zu schwer kontrollierbar sind.
    Gerade diese Komplexität zeigt, wie massiv die Web-Standards geworden sind, die die Browserentwicklung so schwierig machen.
    Es wirkt, als würden sich Designentscheidungen aus Netscape-Zeiten bis heute auswirken und die Wurzel von Sorgen wie Browser-Monokultur oder Finanzierungsproblemen bilden.

    • Es kommt darauf an, welches Linux gemeint ist.
      Auf Android/Linux, WebOS/Linux und ChromeOS/Linux wird WebGPU bereits unterstützt.
      Das zeigt allerdings auch, dass Unterstützung für solche Workloads unter GNU/Linux aus Sicht der Browserhersteller keine hohe Priorität hat.

  • Ich freue mich auch auf eine Implementierung für Linux.
    Mich würde interessieren, welche Demos man sich mit WebGPU ansehen sollte.

  • Es sieht so aus, als würde Firefox WebGPU unter Linux vor Chrome unterstützen.

    • Das ist eigentlich etwas überraschend.
      Obwohl dawn (Googles WebGPU-Implementierung) unter Linux ziemlich gut läuft, ist Firefox bei der Unterstützung offenbar trotzdem schneller.

  • Endlich beginnt die Unterstützung für WebGPU, dafür Applaus an alle Beteiligten.
    Es fühlte sich etwas unangenehm an, nur in Chrome mit WebGPU experimentieren zu können.
    Auch Safari hat die Unterstützung inzwischen in einer aktuellen Preview-Version begonnen.

  • Ich verwende wgpu in einem wichtigen Projekt nun seit fast zwei Jahren.
    Ich hoffe, dass diese Ausweitung von WebGPU zu mehr Maintainers führt
    und die Issues, die ich vor 18 Monaten eingereicht habe, schneller gelöst werden.
    Ich habe Rust bisher noch nicht angerührt, hoffe aber, irgendwann Motivation und Zeit zu finden, selbst beizutragen.
    Ich bin auf die wgpu-native-Bindings angewiesen, dort kommen Updates nur langsam an.
    Zum Beispiel sind wir erst letzte Woche endlich auf v25 gegangen, obwohl vor wenigen Tagen schon v26 erschienen ist.