SIGGRAPH 2008 - 開幕迫る! まずは併催カンファレンス「SANDBOX 2008」の模様をお届け

試作システムでは、GPUでの物理シミュレーション処理エンジンのコーディングにはOpenGLのシェーダ言語のGLSLを使用。本来であればCUDA(NVIDIA)やCAL(ATI)のようなGPGPU言語を活用すべきなのだが、現状ではCUDAはNVIDIA製GPU専用、CALはATI製GPU専用というプラットフォーム依存性があることから、汎用性の方を重視し、あえてグラフィックスプログラミング言語を用いてGPGPUを行う原始的な手法を採択したとしている。GPGPUプログラミング環境がGPUベンダー依存の現状は、開発サイドにとっては踏み絵をさせられているような感覚であり、汎用エンジンを内製開発しようとする中小規模スタジオにとっては辛いようだ。

同試作システムでは、その物理シミュレーションエンジンを動的に切り換える仕組みを何パターンか実装し、そのパフォーマンス効率の検証も行っている。

最も単純なのが、ベンチマーク・テストラン的なフェーズを最初に設け、その結果からCPU、GPUのどちらか高速な方を選ぶというもの。これは、登場オブジェクトがそのシーンで固定されている場合には有効だが、動的に変化する場合には向かない。

動的なシーンに対応させる仕組みとしてはCPUで5フレーム分、GPUで5フレーム分処理してどちらか高速な方でその先90フレーム分を処理するというやり方を提案している。

ただ、この方法だと常に遅いプロセッサの方で5フレーム分処理することになる。そこで、オブジェクト数が何個でCPUとGPUの高速な方が逆転するのかを最初のベンチマークテストランで求めて、シミュレーション中はその登場オブジェクト数に応じて切り換える方法や、登場オブジェクト数が大幅に変動したときだけCPUとGPUのどちらが早いのかを計測するテストランフェーズに移行させるアイディアなどを提案している。

レポートでは、研究グループのテストシステムにおいて、登場オブジェクト数が512個と1024個の間でCPUとGPUにおけるパフォーマンスの逆転が起きた、と報告している。

画面を見ても分かるように、今回のテストケースではグラフィックス処理側はとても軽いものであり、いうなればグラフィックスレンダリングにおけるGPU負荷が軽いものであった。実際の3Dゲームではよりリッチな3Dグラフィックスを処理するので、3Dグラフィックス負荷が大きいときにはGPUは物理シミュレーションを実行する余裕がなく、むしろCPUで実行した方が高速、というケースも出てくるだろう。

いずれにせよ、システムの負荷バランスに応じて物理シミュレーションを処理させるプロセッサをCPUとGPUとで使い分ける……というアイディアは、PCおよび今世代のゲーム機において、今後、注目されるべき技術となることだろう。