西川善司連載 / 完全理解「3DMark Vantage」（4）CPU Test＆スコアの計算方法

　第3回で「3DMark Vantage」の「Graphics Test」を見てきたが，今回は，CPUベンチマークとなる「CPU Test」そして，Game TestとCPU Testから求められる総合スコア「3DMark Score」の算出方法を説明していきたい。

　CPU Testは，Graphics Testと比べると地味ではあるのだが，3DMark Scoreと密接に関わってくる項目なので，テスト結果からマシンのボトルネックやアップグレード方針を読み取ろうとする中級〜上級ユーザーにとっては無視できないテストといえる。

　3DMark VantageにおけるCPU Testは，「近未来のゲームタイトルで活用されるであろうアルゴリズムやソフトウェアパラダイムによってCPUに負荷を掛け，その処理速度を見よう」というコンセプトに基づいている。テスト項目としては

• CPU Test 1（AI Test）：Merry Go Round AI Show
• CPU Test 2（Physics Test）：Crash’n’Burn Physics

が用意されており，（　）内に示されているように，CPU Test 1はAIの負荷，CPU Test 2は物理シミュレーションの負荷がCPUにかかる。何が行われているのかを分かりやすく見せる，また，そしてゲームに用いられそうなソフトウェア負荷にする意味合いもあって，テスト経過はグラフィックスとして視覚化されるのが特徴だ。

　ただし，GPU負荷が高すぎてはCPU負荷のテストにならない。そのため，極力GPUに負荷をかけない方針でのグラフィックスエンジン活用となっている。具体的には，ブルームやモーションブラーといったポストプロセスはすべてキャンセルされ，複雑なマテリアル（＝素材）シェーダ，影の生成も省略される。さらに，ジオメトリ負荷を最小限にするため低ポリゴンモデルが用いられ，画面に見えている部分以外は3Dセットは存在しない。解像度もプリセットを問わず1280×1024ドット固定だ。
　あくまで「CPUに高い負荷をかけるソフトウェアをどう処理するか」を見るためのテストなので，3Dグラフィックスは「結果を分かりやすく見せるためのインジケータ」としてしか利用されない。CPU Testでグラフィックスをチェックするのは意味がないので，この点は憶えておこう。

　CPU Test 1となるMerry Go Round AI Show。複数のゲートが設けられた渓谷地帯で，飛んでいる複数の複葉機はそれぞれ，決められた順番で，ほかの複葉機よりも速くゲートをくぐるよう，AIが仕込まれている。

　ここでいうAIとは，いわゆる「経路探索アルゴリズム」に相当する。空中なので，3次元的な経路探索だ。AIに課せられたルールは三つで，

• ゲートは必ず順番にくぐること
• 近似的な飛行シミュレーションに基づいて飛行すること（※急転回はできない）
• ほかの機体や地面と衝突しないよう避けること

が課せられている。
　このとき行われる経路探索は簡単にいうと2ステップで，まず「この機体は目的のゲートに向けてこう飛ぶ」という経路候補をランダムに生成し，次のステップでその経路候補から「ほかの機体と衝突しない条件」「地面に衝突しない条件」に配慮して最適な候補を選出する。

CPU Test 1，Merry Go Round AI Show実行中の様子。渓谷を複数の複葉機が飛び回る

　これは，「たくさんの候補を算出し，そのほとんどを破棄する」という，高負荷かつ非効率的なメソッドだが，それでも，Futuremarkでは結果に満足しているという。
　Futuremarkのアルゴリズムでは，計算時間に上限を設けた場合，候補が少なく，候補判定の件数も少なくなるわけだが，この「計算時間上限設定」と「経路探索結果精度」の関係性は緩やかであり，調整しやすいとのこと。また，この経路探索＆経路判定の二段判定アルゴリズムは，気球やロケットなど，ほかの種類の飛行物体にも応用できると，Futuremarkは自負している。

　経路生成と経路適性判断の処理はマルチスレッド実装されており，各機体の経路探索，経路適性判断はそれぞれ1スレッドとして発行されてスレッドプールに溜め込まれ，1CPUコアにつき1スレッドが実行可能なスレッド処理形態になっているという。つまり，CPUコアが多ければ多いほどパフォーマンス上昇が見込めるということだ。CPUメーカーには嬉しい設計といえなくもない。
　テスト中に表示される下部左端の項目「OPS」は「Operations Per Second」の略で，秒間何件の経路探索を成功させたかを示している（※表記に若干のブレがあり，「Plans/s」と書かれる場合もある）。下部中央の項目「Operations」はその時点でいくつの経路探索を成功させたかの累積値になる。この値が大きければ大きいほど処理が高速，つまりはCPUパフォーマンスが高いというわけだ。

こちらは3DMark06のCPU Test。解像度640×480ドットで実行されていた

　AIによる経路探索というのは，「3DMark06」のCPU Test「Red Valley」でも実装されていた。しかし，あちらはグラフィックスこそ3Dだったものの，処理自体は「地面に這いつくばった戦車による，2Dの経路探索」だった。その点，Merry Go Round AI Showでは，飛行機の経路探索，すなわち3D空間の経路探索となったところで要素が増え，複雑性が高くなったといえる。
　経路探索ということもあり，各複葉機の飛行経路は実行のたびに異なる。そのため，スコアは微妙に異なる可能性があるが，実行演算数が膨大であり，大局的に見ればブレは極めて軽微だ。スコアがCPUラインナップの上下関係を覆すようなことは，まず起こりえない。

　ちなみに，テスト中に見られる宙返りや旋回といった各機体の飛行アクションは，実際に飛行物理をシミュレートしているわけではなく，あらかじめ用意しておいた飛行アニメーションをそれっぽくつないで見せているだけと，Futuremarkはホワイトペーパーの中で種明かしをしている。

　CPU Test 2のCrash’n’Burn Physicsには，物理シミュレーション負荷テストというテーマが与えられている。

　複葉機がゲートを通過しようとする点ではCPU Test 1とよく似たCPU Test 2だが，こちらでは，より少ない数のゲートを複数の複葉機が通過しようとするため，お互いが衝突して墜落する情景が描かれる。物理シミュレーションが用いられるのは，その飛来する複葉機同士の衝突判定や，破壊された破片が飛散する挙動などの制御だ。

　Crash’n’Burn Physicsの特徴は，物理シミュレーションエンジンとして旧AGEIA Technologies（以下AGEIA），現NVIDIAのPhysXライブラリ「NVIDIA PhysX」を使っている点にある。
　実行するとすぐ，Merry Go Round AI Showと比べて“重い”ことに気づくと思うが，これは，テストシークエンスに登場するほぼすべてのオブジェクトに物理的なパラメータが設定され，リアルタイムの物理シミュレーションが行われているためだ。

CPU Test 2では，複葉機同士が衝突しバラバラになる。この衝突判定，飛散制御などには剛体物理シミュレーションが適用される

青や赤といった煙の挙動には流体物理シミュレーションが適用される

ドーナツ型のゲートは風船，二本柱のゲートはスポンジみたいなリアクションをする。これも物理シミュレーション制御だ

　具体的に説明すると，まず複葉機は12個の剛体パーツから構成され，各パーツは仮想的な糊（のり）で接合されている。そのため，衝撃を受けたときの壊れ方は，12個のパーツ単位になるわけだが，「どう壊れるか」は衝突の仕方に依存し，さらに飛散する破片（＝各剛体パーツ）の挙動も，アニメーションやスクリプトではなく，PhysXライブラリの剛体物理シミュレーションによって決定されている。

　“飛行機っぽい”偽の挙動を合成していただけのCPU Test 1とは異なり，CPU Test 2では，PhysXライブラリベースの簡単な航空力学（＝飛行物理）によって決定されているため，機体数が多いこともあって，これも結構な負荷要因となっているようだ。
　各機体は赤や青の煙を吐きながら飛行するが，この煙の挙動は――ボリュームではなく，おそらくパーティクルシステムベースのものだと思われるが――PhysXライブラリにある流体物理シミュレーションを利用して実現している。

　また，ゲートには浮遊するドーナツ型と，2本柱型のものがあり，それぞれユニークな物理パラメータが設定されているのも，負荷を高めている。
　ドーナツ型ゲートは加圧された布袋，すなわち風船のような物体で，2本柱型ゲートはゴムやスポンジのような塑性体（そせいたい，変形しやすいものの意）の物理パラメータが設定されている。そう，ゲートにはソフトボディ（＝柔体）物理シミュレーションが適用されているのだ。もちろんPhysXライブラリを用いての実装である。

　ところで，Crash’n’Burn Physicsで使われているPhysXライブラリは，旧AGEIAのPPU（PhysX Processing Unit）に対応しており，システムにPhysXアクセラレータ（＝PPU搭載カード）が搭載されていれば，物理シミュレーションのハードウェアアクセラレーションが有効になる。もちろん，有効になるとパフォーマンス，そしてスコアは向上し，しかもこのスコアは公式なスコアとして取り扱われるのだ。

　NVIDIAは，GeForceベースのPhysXアクセラレーションを実現する「GeForce PhysX」を推進しており，本稿が掲載されるタイミング（※2008年7月上旬時点）ではドライバのβテスト中である。実際，4Gamerが行ったβドライバの検証でもスコアは大きく向上しており，GeForce PhysXが正式リリースを迎えると，CPU Test 2は，NVIDIAが俄然有利なテストになるはずだ。「PhysXアクセラレーションもGPUの機能」という観点では問題ないと言えるが，エンドユーザーの心情的には「それってどうなの？」という部分もあると思われ，第3回で説明したオプション設定にある「Disable PPU」は，もしかするとこの先，頻繁に利用されることになるかもしれない。

　なお余談になるが，Graphics Test 1: Jane Nashにおける水面の波動シミュレーションなどといったGPU物理はPhysXライブラリとは関係ないため，PPUやGeForce PhysXでアクセラレートされたりはしないので，この点は憶えておこう。

　PPUやGeForce PhysXによるアクセラレーションに注目が集まりがちなCrash’n’Burn Physicsだが，もちろんマルチスレッド処理に対応している。興味深いのは，CPUコアの数とPhysXアクセラレーション機能の有無で，ゲートのペア（※ドーナツと2本柱，以下便宜的に「ゲートペア」と呼ぶ）の数が変化するという点だ表1。

GeForce PhysX＋クアッドコアCPU（※GeForce 9800 GTX＋Phenom X4）だと，4＋4−1で7ゲートペアが作られる

　やや法則性が見えにくいかもしれないが，PhysXアクセラレーション機能が有効でないシステムにおいては，CPUコアの数だけゲートペアが生成される。そしてPhysXアクセラレーション機能が有効な場合には，まずCPUコアの数に関係なく四つのゲートペアが生成され，同時にCPUコアの一つがPhysXアクセラレーション機能の制御に取られる。そのため 4＋（CPUのコア数−1） 個のゲートペア数になるということだ。例えばクアッドコアCPU＋PhysXアクセラレーション機能有効だと，4＋4−1 で7ゲートペア，というわけである。

　なんでこのような実装になっているのかというと，CPU Test 2は一つの大きなシーンのように見えて，実際はゲートペアごとにシミュレーションの単位がぶつ切りになっているからだ。

　もう少し分かりやすく説明してみよう。

　ゲートペアが1スレッド割り当てとなっていて，各ゲートペア（≒各スレッド）は“自分達”をくぐってくる複葉機を管理している。だから，各機の飛行処理，衝突判定（および破壊）処理，飛散処理といったジョブを，ゲートペア単位で処理しているのだ。
　そう，Crash’n’Burn Physicsで行われている実際の処理は，まったく統合されていないのである。実のところ，各ゲートペアで管理されている複葉機と，ほかのゲートペアで管理されている複葉機との衝突は無視される。CPU Test 2の物理シミュレーションは，あくまでもゲートペア単位で独立して行われており，異なるゲートペアの物理シミュレーション同士は干渉せずに，常に並列で動作できるようになっている。

　端的に述べて，ゲームにおける物理シミュレーションの実装形態としてCPU Test 2のそれはあまり現実的でない。一般的なゲーム設計では，本来なら適当なタイミングで，異なるゲートペア管理下の複葉機同士の衝突も“取る”べきなのだ。Futuremarkはこの件について，「同期を取らない，単純な並列処理モデルの実装によって，各スレッド（※筆者注：CPUコアやPhysXアクセラレータ）は，他者の都合を待つことなくマイペースで処理を進められるようになった」という当たり前の理由を述べている。
　したがって，テストの目的は，そのシステムの物理シミュレーションの「実効パフォーマンス」ではなく「最大パフォーマンス」を見るものという感じになるだろうか。

　テスト結果はCPU Test 1と同様にOPS（Operations Per Second）とOperationsで表される（※こちらも表記にややブレがあり，OPSではなく「Steps/s」と書かれる場合もある）。1Operationは，各ゲートペア管理下で，飛行処理や衝突判定，飛散処理などの各種物理シミュレーションのタスクを一つこなせた時点でカウントされる仕様だ。
　計測はゲーム内時間ではなく現実時間での計測であり，遅いシステムならば複葉機がほとんどクラッシュせずにテストが打ち切られるし，高速なシステムや並列度の高いシステムであればあるほど多くの複葉機がクラッシュして，Operationカウントは大きくなる。同じ並列度でも，例えば動作クロックが高いCPUのマシンのほうが計測時間内にたくさんの飛行機が衝突分解して散らばることになり，その分Operationカウントが大きくなる理屈である。

　セットアップファイルをダウンロードできる4Gamerのミラーページでも説明されているように，3DMark Vantageでは，総合スコアの前に，各プリセットのイニシャルが付くようになった。
　第3回で説明したように，プリセットはEntry，Performance，High，Extremeの4種類。それぞれのプリセットでテストを実行すると，「E」「P」「H」「X」の文字が付くわけだ。Extremeが「X」なのは，いうまでもなく，Entryの「E」と区別するためである。

　実際の計算方法だが，これがちょっと変わっている。

　まずGraphics Test系は二つあるGraphics Test 1とGraphics Test 2の平均フレームレート「F_GT1」と「F_GT2」に対して，あらかじめFuturemarkが用意している定数係数「C_GT1」「C_GT2」をそれぞれ掛け合わせ，足したものがGraphicsスコアになる。計算式としてまとめると，以下のような感じだ。

• Graphics Score＝（C_GT1×F_GT1＋C_GT2×F_GT2）

　CPU Testのスコアの計算方法も同様だ。
　CPU Test 1とCPU Test 2におけるそれぞれの平均OPS値「O_CPU1」および「O_CPU2」に対し，CPU Test 1用の定数係数「C_CPU1」とCPU Test 2用の定数係数「C_CPU2」をそれぞれ掛け合わせ，足し合わせたものがCPU Scoreとなる。念のため，こちらも計算式を示しておこう。

• CPU Score＝（C_CPU1×O_CPU1＋C_CPU2×O_CPU2）

　最終的な3DMark Scoreは，求めたGPU ScoreとCPU Scoreの調和平均で求められる。このとき，Futuremarkがプリセットごとにあらかじめ設定してあるプリセット重み係数「W_Graphics」「W_CPU」が，プリセットごとにスコアを補整する役割を担う。計算式は以下のとおりだ。

• 3DMark Score
  ＝1÷（（W_Grpahics÷Graphics Score）＋（W_CPU÷CPU Score））

　なお，C_GT1，C_GT2，C_CPU1，C_CPU2，そしてW_GraphicsとW_CPUの値は表2のとおり公開されている。

　例えば，Performanceプリセットで，F_GT1が16.04，G_GT2が18.09，F_CPU1が688.34，F_CPU2が17.96の場合は，

• Graphics Score
  ＝int（16.04×（2500÷14.4）＋18.09×（2500÷14.9））
  ≒5819

• CPU Score
  ＝int（688.34×（2500÷477.9）＋17.96×（2500÷12.0））
  ≒7341

• 3DMark Score
  ＝1÷（（0.75÷5819）＋（0.25÷7341））
  ≒6137

で，PerformanceプリセットのPが付いて「P6137」ということになる。

とある環境でPerformanceプリセットを実行した結果

　Futuremark出典の資料では，もう少し複雑な計算式になっているのだが，本稿では分かりやすくするため，式を少し変形している。本質は同じなので，ご了承いただきたい。

　さて，先ほどの表2における定数係数の設定を見る限りでは，どうも2500あたりを基準点に据えている意図が読み取れる。また，四つのプリセットにおけるW_GraphicsとW_CPUの重み係数はFuturemarkが経験的に導き出した値のようだが，EntryからExtremeへ，高負荷になるにつれてCPU Scoreの存在感が薄れていっている（＝3DMark ScoreにCPU Scoreが与える影響を小さくしている）のも分かる。すなわち，3DMark Vantageでより高い3DMark Scoreを狙うのであれば，CPUよりもGPU＝グラフィックスカードに投資したほうが効率がいいということだ。