ハクソク

世界を動かす技術を、日本語で。

Firefox 141におけるWindows向けWebGPUの配信

314日前原文(mozillagfx.wordpress.com)

概要

  • Firefox 141 でWindows向けに WebGPU を正式リリース
  • WebGPU は高性能な計算・描画をウェブにもたらす新世代API
  • Mac・Linux・Androidでも順次対応予定
  • 実装は Rust製WGPU に基づき、オープンソースで開発
  • パフォーマンスや仕様準拠の改善も継続予定

Firefox 141でWindows向けWebGPU正式リリース

  • 長年の開発 を経て、 Firefox 141 でWindows向けにWebGPUをリリース
  • WebGPU はウェブコンテンツからグラフィックスプロセッサ（GPU）を直接制御できる モダンなインターフェース
  • ゲーム・可視化・ローカル計算など ウェブ上の表現力向上 を期待
  • webgpufundamentals.org でチュートリアル、WebGPU Samplesでサンプル体験、MDNでAPIドキュメント提供
  • W3C 標準「WebGPU」と「WGSL」に準拠、Mozillaは2017年から標準化に参加

各プラットフォームへの展開計画

  • Google Chrome では2023年からWebGPU利用可能
  • Safari 26 でも今秋対応予定
  • Firefox 141 ではまずWindowsのみ対応
    • 今後数ヶ月以内に Mac・Linux にも展開予定
    • 最終的に Android にも対応計画
  • ユーザーの大半がWindows利用のため、優先リリース
  • 他プラットフォームでも 十分な安定性・テスト網 が整い次第対応
  • Linuxユーザー の開発者も在籍、他プラットフォーム対応への強い意欲

FirefoxのWebGPU技術基盤

  • Firefox Nightly では既にAndroid以外の全プラットフォームでWebGPUを試験提供
  • 実装は Rust製WGPUクレート を採用
    • Direct3D 12、Metal、Vulkan など各プラットフォームの低レベルAPIに統一的インターフェースを提供
    • GitHub 上で独立したオープンソースプロジェクトとして活発に開発
    • Mozillaも主要なコントリビューター
    • Rust開発者 でWebGPUに興味があれば、まずWGPUプロジェクトへの参加が推奨

今後の課題と改善

  • WebGPUは大規模かつ複雑なAPI
    • まずは 目立つアプリやデモ の安定動作に注力
    • Firefox 141で多くの用途に十分利用可能と判断
  • 今後は パフォーマンス と 仕様準拠 のさらなる向上が課題
    • WebコンテンツからGPUサンドボックスへの通信 が非バッファ方式でオーバーヘッド大
      • Bug 1968122 で大幅な性能改善、修正はFirefox 142で反映予定
    • GPUタスク完了検知 にインターバルタイマー利用中で遅延発生
      • より効率的な方式へ移行中、 Bug 1870699 で進捗公開
    • importExternalTextureメソッド未対応
      • GPUがデコーダから直接非圧縮動画を読み込む機能、 Bug 1827116 で対応進行中

ユーザーへの呼びかけ

  • FirefoxでWebGPUをぜひ試用 し、問題発生時は BugzillaのWebGPUコンポーネント へ報告を推奨
    • バグ再現手順や about:support の内容添付が重要
  • エンジン開発は一段落 し、日常利用に向けてWebGPUを本格公開
  • Firefox上でのWebGPU活用例 に期待

参考リンク

  • webgpufundamentals.org ：WebGPUチュートリアル
  • MDN ：WebGPU APIドキュメント
  • WebGPU Samples ：実用サンプル集
  • GitHub WGPUプロジェクト ：Rust実装の詳細・コントリビュート情報

Hackerたちの意見

ありがとう！Linuxの実装も楽しみだね。これがリリースされたときに試す価値のあるWebGPUデモってある？

└

これ、かなり印象的だと思ったよ：https://huggingface.co/spaces/webml-community/kokoro-webgpu WebGPUなしでも動くけど、めっちゃ遅いよ。

└

https://threejs.org/examples/?q=webgpu （WebGPUが使えない場合はWebGLにフォールバックするよ）

└

見たサイトのほとんどは確かにデモばかりだね。特にCompute Toys [0]、WebGPU用のShadertoyクローンが好きだな。[1]がデモを見つけるのに一番いい場所かも。自分でもWebGPU Compute Shadersを使って実験してるサイトがあるよ。[2] [0] https://compute.toys/ [1] https://github.com/mikbry/awesome-webgpu [2] https://github.com/s-macke/WebGPU-Lab

└

自分がすごく楽しんで作ってるおもちゃがあって、動画エフェクトを作るのに使ってるんだ。 https://vester.si/motion/

└

これが最も印象的なデモの一つだと思う: https://github.com/ArthurBrussee/brush Gaussian splattingトレーニングとレンダリングをWebGPUで使ってる。

└

他のコメントに追加すると、(ほとんどの) Bevyの例はWebGLとWebGPUの両方で利用できるから、比較に便利だよ。 https://bevy.org/examples-webgpu/ + https://bevy.org/examples (WebGL)

└

知っているアプリのインデックスがあるから、よかったら見てみてね： https://bugzilla.mozilla.org/show_bug.cgi?id=webgpu-apps

└

一部のUnityデモ: 1. https://boat-demo.cds.unity3d.com/ 2. https://www.keijiro.tokyo/WebGPU-Test/ 3. https://www.chatlord.com/4/

やっと来た！関わったみんなにお疲れ様！今までChromeだけでWebGPUをいじるのはちょっと気が引けてたから、Safariも最近プレビューを有効にしたし、嬉しいよ。

これが見られてすごく嬉しい！というのも、私たちのgpu-allocator [0] クレート（今はwgpuのdx12バックエンドで使われてるけど、vulkanやmetalもサポートできる）が、今まで使ってたよりもずっと広いオーディエンスに届くことになるから。今まではGPUベンチマークスイートのevolveを出荷するために使ってたんだ。[1] [0]: https://github.com/Traverse-Research/gpu-allocator/ [1]: https://www.evolvebenchmark.com/

└

よくやった！FirefoxがWebGPUを作る手助けをしてくれてありがとう。

まだWebGPUが非ウェブ用途でも普及することを期待してるんだ。そうすれば、公式な仕様のある使いやすいクロスプラットフォームAPIが手に入るから（OpenGLの代わりになる）。でも、Rustの世界以外では、ネイティブコードでWebGPUを使いたいっていう興味はあまりないみたい。例えば、Dawnを使ってる大きなプロジェクトは知らないな。理由の一つは、WebGPUがちょっと遅れて登場したからで、みんなすでにdx、vulkan、metalのカスタムビルドの抽象化を使ってたからだと思う。

└

もう一つの理由は、WebGPUがVulkanほどの最適化や制御を許可していないことと、パフォーマンスがVulkanほど良くないことかもしれない。WebGPUにはVulkanの持っているすべての拡張機能もないしね。

└

ミドルウェアって呼ばれてるもので、ブラウザの外でWebGPUを待つ必要はないよ。ブラウザのサンドボックスにターゲットを絞ったAPIデザインの制約があるけどね。

└

ならないよ。ちょっとは簡単だけど、機能がかなり欠けてる。Vulkanでオプションになったもの（レンダーパス）は、WebGPUではまだ必須だし、バインドグループは静的で面倒だよ。それに、ホストからバッファのサブリージョンに簡単に転送できなかったり、ステージングバッファが必要だったりする制限も追加されてる。代替手段がないからウェブでは使うけど、デスクトップではまともで現代的なグラフィックスAPIが出てくるまで、OpenGL+CUDAのインターフェースフレームワークを使い続けるつもり。つまり、レンダーパスや静的パイプライン、必須の明示的同期、バインディングやデスクリプタセットを排除したグラフィックスAPIが必要なんだ（単にバッファとポインタを使うだけ）。バッファの割り当てやデータの格納が単純なcuMemAllocやcuMemcpyよりも手間がかかるなら、もう無理だね。

「今後数ヶ月でMacとLinux向けにWebGPUを出荷する予定で、最終的にはAndroidでも。」 いいね。でも今のところあんまりワクワクしてないな。理由は何であれ、Linuxのブラウザではまだサポートされてないし。推測だけど、ひどい攻撃面を作らずに公開するのが難しいんじゃないかな。これって、ウェブ標準がユーザーが実際にウェブを使う方法に対して過剰になってるっていう自分の意見を裏付けてる気がする。今さら何かを変えるのは遅すぎるけど、モノカルチャーや資金調達の問題は、Netscapeの時代に遡る決定から来てるんだよね。

└

どのLinuxかによるけど、Android/Linux、WebOS/Linux、ChromeOS/Linuxではサポートされてるよ。ただ、これがGNU/Linuxがこの種のワークロードにどれだけ関係してるかを証明してる気がする。

FirefoxでWebGPU/wgpuが出荷されるのが本当に楽しみ！おめでとう、そしてこれをサポートしてくれたMozillaに感謝！

└

ありがとう！その過程での助けを忘れないよ。

自分の見解では、今のグラフィックスAPIの状態はOpenGL時代よりも悪化してると思う。約束されてるけど、現代のAPIは使いやすくも、真にポータブルでも、クロスプラットフォームでもない。VulkanやMetal、DirectX12の周りにカスタムラッパーを作ってOpenGLを再発明するのは、すごく時間の無駄だし、パフォーマンスのためにすべてのモダン言語で文字列を落として生のchar配列に戻るのも意味がないよ。

└

ほんと、今の状況はちょっと狂ってるよね。大人もいないし、間違いを避けるために導いてくれるリーダーもいない。どんどん深みにハマっていくばかりだよ。

└

問題が見えないんだけど。グラフィックススタックにはずっと低レベルのAPIがあったし（例えば、MesaのGallium）、今はそれが標準化されて、実際に使う人が増えてるだけだよ。高レベルのAPIが今存在しないわけじゃないし、OpenGLはまだちゃんとサポートされてるし、WebGPUもしばらく前からネイティブコードで使えるようになってる。あの低レベルAPIの真のポータビリティについては、基本的にAppleが悪いと思う（ゲーム機メーカーもだけど、彼らが協力するとは誰も思ってなかっただろうし）。

└

現代のグラフィックスAPIは、アセンブリ言語のグラフィカルな同等物みたいなもんだよ。直接使うべきじゃなくて、プログラミング言語やグラフィックスエンジンみたいな高レベルのレイヤーを通して使うもの。ツール作成者向けの専門的なAPIなんだ。

└

誰が、どんな約束をしたの？グラフィックスAPIは、使いやすさを第一の目標にしてきたことはないよ。コードとデータをできるだけ早くGPUに送り込むことが主な目的だから。DevExはそれに比べて常に二の次だと思う。WebGPUはブラウザで計算とレンダリングを公開するための decent なラッパーだと思う。完璧ではないけど、今までのWebGLやOpenGLよりはずっと発見しやすくて直感的だよ。

└

同意するよ。何かもっと良いものが出てくるまで、OpenGLとCUDAのインターフェースを使い続けるつもり。Vulkanはそれじゃない。OpenGLから離れようと思ってVulkanを試したけど、結局CUDAの方がずっと扱いやすかった。Vulkanは過剰に設計された複雑さがあって、全くメリットがないよ。

└

OpenGLはまだまだ強力な技術だよ。Vulkanが使いにくいから、いつも使ってる。残念だな、oglがほとんど死にかけてるせいで、良いソフトウェアがたくさん作られないのが。

└

そうでもないよ。例えば、OpenGLの時代にはゲーム機がOpenGLを使ってるっていう都市伝説があったけど、実際にはそんなことはなかった。任天堂はN64のようにCやC++が使える開発キットに移行した後、OpenGLにインスパイアされたAPIを持ってたけど、実際には同じじゃない。GLSLのようなシェーダーサポートもあったけどね。スイッチで初めてKhronosのAPIをサポートし始めたし、完全なスイッチの力を引き出したいならNVNを使うのがベストだよ。プレイステーションは常に独自のAPIを持っていて、少しだけOpenGL ES 1.0 + Cgを使ったけど、開発者の間ではほとんど受け入れられなかったから、開発キットからは外された。セガも独自のAPIしか持ってなくて、DirectXとの小さなコラボレーションがあったけど、利用したスタジオはほんの一部だった。Xboxは当然DirectXが中心だよ。GDC Vaultのプログラミングトラックを見て、ミドルウェアをゲームエンジンのために書くことに文句を言ってる開発者がどれだけいるか、逆にハードウェアアーキテクチャの低レベルの詳細を活用することについて話してる人がどれだけいるかを見てみて。

└

OpenGLは2.0以降、めちゃくちゃなAPIになっちゃったけど、WebGPUは実際にはVk、D3D12、Metalの周りに作られたかなり使いやすいラッパーなんだよね。OpenGLが今なってるのより、ずっと設計が良いと思う。それを除けば、D3D11とMetalv1が使いやすさとパフォーマンスのバランスが一番いいかも。特にD3D11は、VulkanやD3D12でもなかなか勝てないくらいだし。

WebGPUがもうmacOSのFirefox Nightliesで使えるなんて気づかなかった！ https://www.mozilla.org/en-US/firefox/channel/desktop/ からMacのナイトリーをインストールしたら、これが動いたよ： https://huggingface.co/spaces/reach-vb/github-issue-generato... SmolLM2モデルがWebAssemblyにコンパイルされて、構造化データの抽出ができるんだ。前はこのデモはChromeでしか動かないと思ってたのに。（普通のMac用Firefoxで試すと「エラー：現在の環境ではWebGPUがサポートされていませんが、WebLLMエンジンを実行するには必要です。」って出る。）

└

FirefoxのWebGPUチームのメンバーだよ。これは予想通りだね。macOSの安定したサポートは、すぐに出荷できることを期待してるよ！ 投稿から：> Firefox 141はWindowsでのみWebGPUを有効にするが、今後数ヶ月でMacとLinuxにWebGPUを出荷する予定で、最終的にはAndroidにも対応する予定だ。

どうやらFirefoxがLinuxでWebGPUを出荷するのはChromeより早そうだね。

RTXレイトレーシングのネイティブ命令をGPUでサポートすることで、大きな一歩を踏み出せるよ。