再現性の高い WebGL GPU ベンチマーク：プリセット・エクスポート・共有リンク

なぜ再現性が難しいのか

フレームレートの数字自体は簡単に出せても、比較可能なデータにするのは難しいものです。ブラウザーによって GPU バックエンドが異なり、OS がタスクをスケジュールする方法も違います。ドライバーの更新でシェーダーのコード生成が変わることもあります。シーンや解像度、シェーダーパラメーターが毎回変わってしまえば、ベンチマークは客観的な測定ではなく「雰囲気の確認」に終わってしまいます。

私たちはパイプラインをシンプルにし、ワークロードを明示するアプローチを取りました。マンデルバルブフラクタルをレイマーチングするボリュームシェーダーを固定し、カメラも決定論的な軌道を描きます。調整可能なパラメーターはすべて公開し、URL にエンコードできるようにしました。これにより、数週間後でも、別のマシンでも、高い確度で同じ実行を再現できます。

ケーススタディ：ベンチマーク結果を共有する

例として、Balanced プリセットをベースに反復回数を 10、ステップサイズを 0.0025、解像度スケールを 1.0 に設定するとします。ノート PC で平均フレーム時間が約 14 ms、最小値と最大値の幅も狭いと確認できたら、Share をクリックしてリンクを生成します。このリンクをデスクトップ GPU を持つ同僚に送ると、ページが自動的に同じ設定を適用して描画を開始します。相手のフレーム時間が 8〜9 ms 付近で安定するなら、その差はハードウェアによるものだと判断できます。

次に、解像度スケールだけを 1.3 に上げて再度共有してみましょう。両者ともピクセル数が増えた分、フレーム時間が比例して増えるはずです。このように単一の変数だけを変えて比較できる点が、公平で再現性の高い WebGL ベンチマークの核となります。

時間を越えて結果を比較する

ハードウェアもブラウザーも日々変化します。過去との比較を行うには、環境情報を忘れずに記録してください。GPU モデル、OS、ブラウザーのバージョン、ドライバーのバージョンをメモし、CSV と共有リンクをセットで保存します。リグレッションが発生したとき、リンクを開けばワークロードの変化かプラットフォームの変化かを切り分けられます。

ベンチマークでよくある落とし穴を避ける

• バックグラウンドアプリやストリーミングタブ、オーバーレイを閉じる。
• テストごとにブラウザーを変えない。同じ Chromium 系でも GPU バックエンドが異なる場合があります。
• ドライバーを更新し、大規模な比較の前には再起動を行う。
• 選択したプリセットで 1 分ほどウォームアップし、ターボクロックの揺らぎを避ける。
• 室温や電源プランを揃えて、環境要因を最小限に抑える。

内部の仕組み：WebGL とレイマーチング

レンダラーは意図的にシンプルです。フルスクリーンパスでカメラ基底を計算し、レイを進ませ、マンデルバルブのカーネルを評価し、法線を求めてシェーディングします。CPU のオーバーヘッドを最小限に抑え、フラグメントシェーダーの計算能力を洗い出す構成です。WebGL ベースなのでネイティブインストールなしで動作し、ポータブルに GPU の挙動を観察できます。

デフォルトでは符号変化を利用したシンプルな改良ステップを採用していますが、距離推定を使った sphere tracing を導入すれば収束を加速できます。ローカルで実験する際は、距離推定版に差し替えて同じプリセットで比較してみてください。アルゴリズムの違いが GPU アーキテクチャにどう響くかがよく分かります。

結論：アクセスしやすさと再現性の両立

WebGL がベンチマークを手軽にし、プリセットが扱いやすくし、CSV エクスポートが追跡可能にし、共有リンクが再現性を担保します。これらを組み合わせることで、美しいフラクタルのデモは信頼できるボリュームシェーダー ベンチマークへと変貌します。ノート PC の更新からブラウザー比較、ドライバー調整まで、再現性を味方につければ意思決定の精度は格段に向上します。