Firefox 141でWindows向けWebGPUを正式提供

 (mozillagfx.wordpress.com)
3 ポイント 投稿者 GN⁺ 2025-07-17 | 1件のコメント | WhatsAppで共有
  • WebGPU が長年の開発を経て、Firefox 141 Windows版で正式にサポートされた
  • WebGPU は最新のグラフィックス処理と高性能計算のための WebベースのGPUインターフェース であり、ゲーム・可視化・ローカル計算の水準を大きく引き上げると期待されている
  • Firefox の WebGPU 実装は Rust ベースの WGPU ライブラリ上に構築されており、Direct3D 12、Metal、Vulkan など多様なバックエンドをサポート
  • 現時点では Windows でのみ正式に有効化されており、Mac、Linux、Android 対応も今後予定されている
  • 依然として 性能改善 や 標準準拠 など、追加の開発課題が残っている

WebGPUのWindows対応の意味

  • 長期間開発されてきた WebGPU が、Firefox 141 で Windows 環境に正式搭載された
  • WebGPU は、Webコンテンツが ユーザーのGPU と直接連携し、高性能な グラフィックス と 並列計算 を実現できるようにする最新標準である
  • この技術により、Webベースのゲーム、データ可視化、機械学習 などさまざまな分野で性能の限界が大きく広がる見込み
  • WebGPU チュートリアル、WebGPU サンプル、MDN ドキュメント を通じて、関連する学習と実践が可能
  • WebGPU は WebGPU W3C 標準 と WGSL 標準 で定義されており、Mozilla は 2017年から標準化プロセスに積極的に参加してきた

ブラウザー別WebGPUの現状

  • Chrome ではすでに 2023年から WebGPU のサポートが行われている
  • Safari 26 では今年秋に提供予定
  • Firefox 141 は現在 Windows のみ正式サポートで、Mac/Linux/Android は今後のアップデートで拡大予定
  • Firefox Nightly ではこれまで Android を除くすべてのプラットフォーム で実験的に利用可能だった

FirefoxのWebGPU実装

  • Firefox の WebGPU は、オープンソースの Rust ライブラリである WGPU を基盤として開発されている
    • WGPU は、各種プラットフォームのハードウェアに合わせて Direct3D 12、Metal、Vulkan などの低レベルグラフィックスAPIと接続される
    • Mozilla は WGPU プロジェクトの主要コントリビューターである
    • Rust 開発者が Firefox WebGPU に貢献したい場合は、WGPU プロジェクトから始めるのが適している
  • WGPU は Firefox 外でも広く使われており、活発なコミュニティが存在する

主な課題と改善作業

  • WebGPU は 大規模で複雑なAPI であり、現時点では主要デモや実運用事例を中心に安定化へ注力している
  • 追加改善が必要な領域:
    • GPU サンドボックスプロセス との 非バッファリングIPC によって生じる性能低下の問題を解決すること（バグ 1968122、Firefox 142 で性能改善予定）
    • GPU 作業の完了時点を インターバルタイマー でしか検知できず、待ち時間が増える問題（バグ 1870699、より良い方法に改善中）
    • importExternalTexture が未対応のため、デコーダーから GPU への映像データ直接読み込みができないこと（バグ 1827116、開発進行中）
  • 実運用で問題が発生した場合は、Bugzilla の WebGPU コンポーネント に詳細を添えて報告が必要

今後の計画

  • Windows の後、Mac、Linux、Android の順で正式サポートを拡大予定
  • 性能、互換性、標準準拠 などを継続的に改善していく計画
  • WebGPU の正式サポートにより、Webアプリケーションの新たな可能性 が開かれると期待される

関連記事

1件のコメント

 
GN⁺ 2025-07-17
Hacker Newsのコメント

  • 本当に楽しみなニュースだ。Firefoxチームにお祝いを伝えたい。
    うちの会社では、Unrealをブラウザで動かせるよう開発しており、Unreal Engine 5向けのカスタムWebGPU RHIを構築した。
    技術デモを実際に見たい人は、以下のリンクを参照してほしい。
    （デスクトップのChromiumベースのブラウザと一部のAndroid端末でのみ動作する）
    Cropout: https://play-dev.simplystream.com/?token=aa91857c-ab14-4c24-963a-36203784474b
    Car configurator: https://garage.cjponyparts.com/

    • Firefox 142（nightly）で試してみた。
      Cropoutは長時間0%のままで、1200件以上のネットワークリクエストが発生していた。
      最終的にはメニューまでは読み込まれるが、背景が黒く、UI要素しか表示されない。
      シェーダー解析時に多くのエラーが発生しており、その他のエラーもあった。
      Car configuratorは複数のエラーを出して0%で止まり、読み込まれない。
      「ゲームファイルが欠落しているため、グローバルシェーダーとコンテンツの初期化が困難」というメッセージが表示された。
      Firefoxでも最低限のテストをしてから共有してほしかった。

    • 「Chromiumベースのブラウザでのみ動作」と明記されているが、この投稿自体がFirefoxのWebGPUについての話なので、
      Firefox互換版をテストしたり公開したりする予定があるのか気になる。

    • Pixel 7aでAndroid Chromeから「cropout」を起動してみたが、0%で止まった。
      「car configurator」は97〜98%までは進むが、それ以降はまったく進まない。

    • Firefox 141を使っているWindowsで動くのか気になる。
      そうでないなら、その理由を知りたい。

    • macOS版Google Chromeでは、最初のリンクは0%で止まって動かず、
      2つ目のデモは98%または97%で止まった。
      Safariでも同じ現象があった。

  • 今のグラフィックスAPIの状況を見ると、OpenGL時代よりむしろ後退しているように感じる。
    現代のAPIは、使いやすさや本当の意味でのポータビリティ、クロスプラットフォーム性を十分に提供していないと思う。
    Vulkan、Metal、DirectX12のような各種グラフィックスバックエンド向けにカスタムラッパーを作るのは、むしろ時間の無駄に近い。
    まるで性能のために文字列ではなくchar配列に逆戻りしているような感覚だ。

    • どんな約束があったのか、誰がそんな約束をしたのか分からない。
      グラフィックスAPIの目的は、あくまでGPUにできるだけ速くコードとデータを渡すことであって、開発者体験が最優先だったわけではない。
      WebGPUはブラウザ内でのコンピュートとレンダリングをかなりうまくラップしていると感じた。
      まだ完璧ではないが、WebGLやOpenGLより直感的で、探索しやすいと思う。

    • 問題がよく分からない。
      グラフィックススタックには昔から低レベルAPIが存在していたし（例: MesaのGallium）、今はそれらが標準化されて、ユーザーが直接選ぶようになっただけだ。
      高レベルAPIも依然として存在し、OpenGLも妥当なプラットフォームではサポートされている。
      WebGPUもネイティブコードでかなり使えた。
      こうした低レベルAPIに本当のポータビリティがない主因は、ほぼAppleとコンソールメーカーにある。
      ただし、コンソールメーカーについてはもともと協力を期待していなかった。

    • OpenGL時代から得た教訓は、すべてのプラットフォームが同じ高レベルAPIを使うことが、必ずしも良い結果を保証しないということだ。
      結局重要なのは、そのプラットフォームのハードウェア制御をうまく行えるAPIがあるかどうかだ。
      OpenGLをそのまま翻訳するラッパーは常に必要で、昔はそのラッパーを避ける方法がなかった。
      各ハードウェアタイプごとに最良の結果を出すやり方は、実用性に欠ける。
      本当に重要なのは、翻訳しやすいレイヤーを提供できるかどうかだ。
      もし本当にハードウェアに深く踏み込みたいなら、単純だったり汎用的だったりするインターフェースよりも、ハードウェアに直接近づけるAPIが必要になる。

    • OpenGLは2.0以降APIがあまりにも複雑化し、WebGPUはVk、D3D12、Metalの機能をかなり扱いやすくラップしている。
      OpenGLよりずっと設計が良いと思う。
      ちなみにD3D11とMetal v1が、おそらく使いやすさと性能の面で最も妥当なバランスポイントだ（特にD3D11の性能はVulkanやD3D12でもなかなか追いつけない）。

    • 私も同意する。
      OpenGLとCUDAの相互運用で開発を続けるつもりだ。
      Vulkanは、過剰設計された複雑さのわりに実用上の利点がなく、そのせいでむしろCUDAを使うことになった。

  • WebGPUがブラウザ外の環境にも成功裏に拡張されて、
    公式仕様で扱われる使いやすいクロスプラットフォームAPI（つまりOpenGLの代替）になってほしいと今でも思っている。
    ただ、Rust界隈を除けば、ネイティブコードでWebGPUを使おうという流れはあまり大きくないように感じる。
    たとえばDawnを使っている大規模プロジェクトは聞いたことがない。
    おそらくWebGPUの登場が遅すぎて、多くがすでにdx、vulkan、metal上に独自の抽象化レイヤーを構築していたからでもある。

    • 結局は広まらないと思う。
      多少の単純さはあるが、機能不足も大きい。
      Vulkanではオプションになっている一部の機能（例: レンダーパス）が、WebGPUでは依然として必須だ。
      バインドグループも静的で、むしろ不便だ。
      さらにWebGPUには、さまざまな制限や不要な要素がある。
      たとえばホストからバッファのサブリージョンへ直接書き込めず、必ず中間バッファ（ステージングバッファ）を使わなければならない。
      代替がないのでWebでは使うだろうが、デスクトップでは引き続きOpenGL+CUDA相互運用フレームワークで進めるつもりだ。
      もっと合理的な現代的グラフィックスAPIが出てほしい。
      cuMemAllocやcuMemcpyで済むような作業が、複雑なバッファ割り当てとバインド、パイプライン、明示的な同期、バインディンググループ、ディスクリプタセットなど不要な要素で複雑になるなら、使いたくない。

    • WebGPUはVulkanほどの最適化や細かな制御を提供せず、性能もVulkanほどは出ない。
      Vulkanにある各種拡張（extension）も、まだWebGPUではサポートされていない。

    • 既存のミドルウェアがすでにある。
      ブラウザ外では、わざわざWebGPUを待つ必要はないと思う。
      そもそもブラウザサンドボックスを前提にしたAPI設計に由来する制約があるからだ。

    • 名前自体も大きな問題だったと思う。
      私は純粋なネイティブ開発者なので、「web gpu」という名前だけ見て何年もの間、単なるWeb専用技術だと思い込んで気にも留めていなかったが、実際には誤解だった。

  • 私たちのgpu-allocator https://github.com/Traverse-Research/gpu-allocator/クレートが、もっと多くの人に知られるようになりそうでとてもうれしい。
    これまではwgpuのdx12バックエンドや、自社のgpuベンチマーク製品evolve https://www.evolvebenchmark.com/で使っていた。
    今後はもっと幅広く活用されることを期待している。

  • macOS版Firefox Nightlyで、すでにWebGPUが使えることを今知った。
    https://www.mozilla.org/en-US/firefox/channel/desktop/ からMac向けnightlyを入れて、
    https://huggingface.co/spaces/reach-vb/github-issue-generator-webgpu のデモを動かしてみたが、問題なく動作した。
    このデモはSmolLM2モデルをWebAssemblyにコンパイルして、構造化データ抽出に使っている。
    これまではChromeでしか動かないと思っていたが、正式版Firefox（Stable）では「WebGPUはサポートされていない」というエラーが出る。

    • Firefox WebGPUチームのメンバーだ。
      macOSサポートはまもなく正式提供する予定だ。
      Windowsに加えて、近いうちにMac、Linux、そして最後にAndroidでもWebGPUをサポートする計画だ。

  • 「MacとLinux、そして最後にAndroidでWebGPUをサポートする計画」という話はうれしく感じる。
    ただ、現時点では大きな期待はしにくい。
    LinuxブラウザでWebGPU対応がこれまで難しかった理由は、おそらく新たな攻撃ベクトル（attack surface）を作る難しさにあると思う。
    こうした複雑さこそが、Web標準の肥大化がブラウザ開発をいかに難しくしているかの証拠だ。
    Netscape時代から続く設計判断の影響が今なお残り、Webブラウザの単一化や資金面の問題などへの懸念の根っこになっているように思う。

    • どのLinuxかによる。
      Android/Linux、WebOS/Linux、ChromeOS/Linuxでは、すでにWebGPUがサポートされている。
      ただ、GNU/Linuxでこの種のワークロードをサポートすることは、ブラウザベンダーにとって優先度が低いことの裏返しでもある。

  • Linux向け実装も楽しみにしている。
    WebGPUが来たら試してみたいデモがあるのか気になる。

  • FirefoxのほうがChromeより先にLinuxでWebGPUをサポートしそうだ。

    • 実際、少し意外だ。
      dawn（GoogleのWebGPU実装）はLinuxでもかなりよく動くのに、それでもFirefoxのほうが先行して対応している。

  • ついにWebGPUサポートが始まり、皆に拍手を送りたい。
    ChromeでしかWebGPUを試せなかったのは少し居心地が悪かったが、
    Safariも最近のプレビュー版でサポートを始めた。

  • 私は主要プロジェクトで、ほぼ2年間wgpuを使っている。
    今回のWebGPU拡大によってメンテナーが増え、
    18か月前に出したissueがもっと早く解決されるようになることを期待している。
    まだRustには手を出していないが、いつか自分で貢献する動機と時間が持てればと思う。
    wgpu-nativeバインディングに依存しているが、更新の反映は遅い。
    たとえば先週ようやくv25になったと思ったら、ほんの数日前にv26が出たところだ。