WebGPUはブラウザーのページがGPU adapterを探し、機能と上限を確認してdeviceを要求し、GPUコマンドやリソースを利用するAPIです。すべての端末で同じ機能や大きさのリソースが使えるわけではありません。adapterとdeviceが示す対応範囲に合わせて機能を選び、device lossやリソース生成失敗に備える必要があります。

WebGPUのアダプター機能と制限を確認してデバイスを要求し、device.lost後に新しいデバイスや代替経路を試す流れ

1. adapterの取得からdevice要求まで

ページはnavigator.gpu.requestAdapter()で利用可能なadapterを要求できます。利用できるGPUがない場合やブラウザー方針で公開されない場合、結果が得られないことがあります。これは通常の代替経路として扱います。adapterを取得したらfeaturesとlimitsを確認します。任意機能を使う場合はrequestDevice()で明示的に要求し、受け取っていない機能を使えると仮定しません。

deviceはGPUリソースを作成し処理を行う主な単位です。device要求で必要な上限を指定できますが、表示された上限は安全に確保できる総メモリ量の保証ではありません。adapterの対応を確認して必要な水準を要求し、取得に失敗したらCPU処理や簡易描画へ切り替えられるようにします。

2. 機能と上限から分かること

featureとlimitはadapterまたはdeviceが対応し許可する範囲を示します。フォーマット、shader機能、リソースサイズがすべての利用環境で使えるとは限りません。未対応の任意機能を要求するとdevice作成が失敗することがあり、許容上限を超えたリソース生成では検証エラーになる場合があります。任意機能は条件に応じて使い、境界値や不正入力も試験します。

上限値はページで利用できる物理メモリの完全な目安ではありません。ブラウザーはハードウェアやドライバーの差を抽象化し、確認後に資源圧迫やシステム状態が変わることもあります。maxBufferSizeを読んだからといって、そのサイズのbufferを多数同時に確保できるとは限りません。必要な容量から始め、生成結果とGPUエラーを観察して負荷に合わせます。

3. device lossとリソースエラーへの対応

GPUDevice.lost Promiseはdeviceが利用できなくなったことを通知します。原因には装置やドライバーの問題、ブラウザーによる終了などがあり得ます。ページは古いdeviceに依存する処理を止め、必要ならadapterと新しいdeviceを取得します。復旧が毎回成功する保証はないため、繰り返し失敗する場合は機能を減らした経路や安全な代替表示に切り替えます。

コマンド送信の前後には検証や実行のエラーも発生し得ます。未処理のGPUエラーイベントを監視すると、局所的に捕捉していない問題の診断に役立ちます。エラー後もリソースが使えると決めつけず、生成段階を分けて失敗位置を絞ります。GPU経路が停止したとき、画面を固めたままにせず、再試行や品質低下の状態を利用者に示します。

4. 専門家の視点:機能差と復旧を含めた設計

W3C仕様はadapterとdeviceの取得、機能と上限の要求、リソース検証、device loss通知を定めます。MDNは機能探索とAPIのセキュリティ・互換性条件を開発者向けにまとめています。どちらもWebGPU対応環境が同じ性能やメモリ予算を提供すると約束しません。実際に配布するブラウザーで返されるadapterとdeviceを試験します。

初期化を失敗し得る段階ごとに分け、adapter不在、必要feature未対応、device要求失敗、上限検証、device lossにそれぞれ記録と代替動作を用意します。原因を分ければ不要な全体再起動を避けられます。GPU処理は任意の高速化経路として設計し、CPUや低機能環境の動作も確認してください。機能確認は現在の環境に合う経路を選ぶ根拠であり、その後の処理成功の保証ではありません。

参考資料