1. 管理されたワークロード生成
選択された解像度、品質、目標FPSプロファイルで、持続的なWebGLシェーダーワークロードを実行します。
手法
このベンチマークがシグナルを作る仕組み
WebGPUStress がワークロードを生成し、フレームデータをサンプリングし、指標を算出して実践的な解釈に変換する方法を説明します。
手法バージョン: M-2026.03
2. 継続的なフレームサンプリング
実行中、各サンプルがフレームレート、フレーム時間分布、目標未満の挙動を記録します。
3. 派生指標の合成
平均FPS、1% Low FPS、フレーム時間の広がり、ドロップ率をサンプルストリームから計算します。
4. 安定性スコアリング
正規化された安定性スコア（0-100）が、ペーシング品質と目標未満の継続性を要約します。
5. 人が読める評価
しきい値ロジックにより、生の指標を「正常」「要注意」「不安定」という実用カテゴリに変換します。
指標の定義
| 指標 | 表す内容 | 解釈上の注意 |
|---|---|---|
| 平均FPS | 選択プロファイルでの持続スループット。 | 平均が高いだけでは滑らかなペーシングは保証されません。 |
| 1% Low FPS | 最も遅い持続的な瞬間の性能。 | 平均との差が大きい場合はスタッターリスクを示します。 |
| フレーム時間の広がり（P95-P50） | フレーム配信の一貫性ウィンドウ。 | 広がりの増加は負荷時の不安定性を示すことが多いです。 |
| ドロップフレーム率 | 選択した目標FPSを下回った時間割合。 | 高い比率は通常、プロファイル過負荷またはスロットリングを意味します。 |
| 安定性スコア（0-100） | 実行全体の一貫性を示す総合指標。 | 必ずプロファイル設定と実行時間と合わせて解釈してください。 |
再現性チェックリスト
- ブラウザ版、GPUドライバー版、電源モードを固定します。
- ハードウェア変更を比較する前に、同一プロファイルを少なくとも2回実行します。
- ベンチマークタブを実行中ずっと前面に保ちます。
- 異なるブラウザ間のスコアを同等として比較しないでください。
- 温度とクロックにはデスクトップテレメトリ（MSI AfterburnerやGPU-Z）を使います。
このFPSテストの測定方法
平均FPS = 1,000 × 間隔数 ÷ 実測ミリ秒。分位点は(N − 1) × pで線形補間します。1% Low = 1,000 ÷ 最長ceil(N × 0.01)個の間隔の平均で、1,000/P99とは異なります。
軽量なFPSテストを実行GPUの確認・レポート・比較の条件
GPU確認ツールとアクセラレーション確認は、共通のWebGPU・WebGL検証処理を使います。WebGPUでは安全なコンテキスト、API、アダプターとデバイスへのアクセス、WGSLコンパイル、64 × 64の三角形描画と画素の読み戻し、4つの数値の計算結果を確認します。WebGL 2とWebGL 1はそれぞれ4 × 4で三角形を描き、中央画素を検証します。APIの公開やコンテキスト取得の成功は「対応」、実行結果まで正しい場合にのみ「成功」と表示します。省略された処理は「未実行」、判断材料がない場合は「不明」です。
WebGPUのadapter.infoとWebGLのWEBGL_debug_renderer_infoは別の情報源として扱います。機種情報は非公開の場合があります。既知のソフトウェアレンダラー名はソフトウェア描画の根拠になりますが、低いFPSやメーカー名だけでは判断できません。小さな処理の成功はハードウェアの健全性やブラウザー全体の高速化を保証しません。バッファーやテクスチャの上限は総VRAM容量、温度、クロックの測定値ではありません。
レポートはスキーマ版1を使い、診断と性能を区別します。指標定義はlegacy-1のままで、既存スコアは変更していません。負荷テストのFPSは総描画フレーム数÷経過秒数、表示スコアは平均FPSの四捨五入です。フレーム時間の標準偏差には標本分散を使います。P50/P95/P99は従来の0.5 ms刻みのヒストグラム（上限200 ms）から求め、1% low FPSは1,000÷P99です。ドロップ率は「目標フレーム時間＋max(1 ms, 目標の8%)」を超えた区間数÷全区間数です。安定性はround(0.45 × consistency + 0.35 × drop score + 0.20 × spread score)。各項はconsistency = clamp(low1Fps / avgFps, 0, 1) × 100、drop score = clamp(1 − drop ratio, 0, 1) × 100、spread score = clamp(1 − (P95−P50) / (1.5 × 目標フレーム時間), 0, 1) × 100です。
従来の負荷テストには独立したウォームアップ区間がなく、時間を0として明記します。シェーダーテストは1280 × 720で3シーンを各10秒測定し、各シーンの最初の3フレーム区間を除外します。除外した実際の時間と残りの測定時間を記録します。平均FPSは1,000÷平均フレーム時間、1% lowは保持した区間のうち最も遅い1%の平均時間から求めます。スコアは3シーンのFPSの幾何平均×100を四捨五入した値です。安定性は各シーンのlow-FPS / 平均FPSの比を平均し、0〜1に収めて100倍します。従来のフィルターは0超・1,000 ms未満の区間を保持します。測定中の異常区間を除外した実行は無効と記録しますが、計算式は変更していません。
安定性ページの低下率は、最初と最後の各20%のサンプル（件数は切り上げ）の平均FPSから、(初期 − 終盤) / 初期 × 100で求めます。負荷テストは通常500 msごとと終了時にサンプルを記録します。出力曲線は、重複しない同数のサンプル群ごとに実経過秒数とFPSを平均し、最大120点にまとめます。比較グラフは実際の秒数を共通軸に使い、短い実行を長い実行に合わせて引き伸ばしません。
ページの非表示、コンテキストやデバイスの喪失、測定失敗、キャンセルされた実行は、性能向上として扱えません。requestAnimationFrameは画面の更新頻度とブラウザーの実行タイミングに依存します。60 FPSという結果だけでGPUが最大負荷とは分からず、目標FPSを上げても表示タイミングの制約は変わりません。FPS低下は観測結果であり、過熱や電力制限の診断ではありません。
このブラウザーのlocalStorageに最大20件を保存します。既存の保存方式を使い、基準として固定したレポートは自動整理でも残します。自動保存設定とメモもローカルに保持します。保存エラーが起きても画面上の結果は残り、JSONで出力できます。以前のシェーダー結果はそのまま残し、明示的な操作で有効性不明として履歴にコピーできます。未知の履歴・スキーマ版は上書きしません。履歴削除は共通レポートを対象とし、保存された旧形式の記録は削除しません。
JSONの読み込み上限は1 MiBです。入れ子のフィールド、単位、有限数、配列を厳密に検証します。同じID・内容の再読み込みは変更を行わず、内容が衝突する場合は拒否します。元の実行日時を保持して外部データと表示し、再実行や独立した検証は行いません。メモや読み込んだ文字列はテキストとして表示します。コピーとJSON出力には、そのレポート自身のフィールドだけを含めます。
性能を直接比較するには、テスト版・指標版、API、処理内容、測定設定が一致し、両方が完了した有効な実行である必要があります。記録された環境やメモが異なる場合は百分率の比較を行いません。物理機器が同一かは独立して確認できません。基準値がない場合や0の場合、相対変化は出しません。比率の変化はパーセントポイントで表示します。診断レポートでは確認項目、機能、上限、機器を比較し、性能向上率は扱いません。小さな差は同条件で再測定してください。ドライバー更新や清掃後の変化だけでは因果関係を証明できません。