長きにわたってねっとりと行ってきた「3DMark06」の解説もこれで最終回。今回はグラフィックスチップのパフォーマンスを“機能単位”で評価するために盛り込まれたFeature Tests(項目テスト)の紹介を行っていきたい。
Feature Testが実行できるのはAdvanced Edition以上の有償ライセンスを取得した環境のみになる
そもそもFeature Testsは,無料のBasic Editionでは利用できず,利用するにはAdvanced Edition以上を購入する必要があるということもあり,どうしても中級者以上に向けたテストになる。また,そのスコアは総合スコアである3DMark Scoreにはまったく影響しない。あくまで,グラフィックスチップが持つ基本機能の性能を個別テストするために用意されたものだ。
だが,この結果を理解し,そのグラフィックスチップやPCシステムの性能特性を知ると,各種3Dゲームにおいてパフォーマンスを落とさずに最高の描画設定を行う大きなヒントになる。例えば,フィルレート性能が低くてもピクセルシェーダユニットの性能が高い場合は,フィルレート性能が影響するディスプレイ解像度を低めに設定しつつ,シェーダユニットの性能が影響する描画設定を最高品質に設定してゲームをプレイする,といった判断ができるようになるだろう。
というわけで,以下,順を追って見ていくことにしたい。
「Fill Rate」は「3DMark2000」で初めて用意されたテスト項目で,内容は基本的に,この頃からほとんど変わっていない。「Single Texturing」「Multi Texturing」という二つの側面から,グラフィックスチップの性能を計測するようになっており,結果はフレームレートではなく,「1秒間に何テクセル適用できたか」を示すテクセル毎秒(Texels/s)で示される。
|
|
|
Fill Rateの表示内容はこんな感じ。なお,画面に表示されるものこそ従来とあまり変わっていないが,テストされる項目自体は3DMark06オリジナルになっているので,この点は注意しておこう
|
●Single Textureing(シングルテクスチャリング)
Single Texturingは,2×2テクセルからなるテクスチャを,64枚の四角形ポリゴン板に適用して半透明重ね書きするテストだ(図1)。
2×2テクセルという小さなサイズのテクスチャが利用されるのは,テクスチャ参照の負荷でグラフィックスメモリ帯域を消費させないためだ。2×2テクセル程度だと,ほとんどの場合,グラフィックスチップ内のテクスチャキャッシュにデータが載ってしまうため,グラフィックスメモリからの読み出しを限りなくゼロに近づけられるのである。
このテストにおいて,ピクセルシェーダユニットの数はほとんど結果に関係せず,グラフィックスチップが持つ,グラフィックスメモリへの出力(書き込み)性能が顕著に現れる。よって,グラフィックスメモリの速度が高ければもちろんスコアは上がるが,それよりも,ピクセルレンダリングパイプラインの本数,もっといえばテクスチャユニットやROPユニットの数に依存した結果になりやすい。先ほど述べたように,テクスチャ自体は常時オンキャッシュ状態となるため,グラフィックスメモリからの読み出しはほとんどないものの,テクスチャを適用する(取得したテクセルデータにフィルタリングなどの処理を行い,結果として返す)処理は実際に行われるので,テクスチャユニットやROPユニットの数が結果に反映されやすいというわけだ。
●Multi Texturing(マルチテクスチャリング)
こちらは,2×2テクセルのテクスチャを8枚を重ねて,それを画面大の四角形ポリゴン板に適用。これを1セットとして,8セットを重ねるようになっている(図2)。
基本的なテストコンセプトはSingle Texturingと同じで,グラフィックスメモリへの書き込み性能や,テクスチャユニット,ROPユニットの数に依存した結果になる。ただ,単位時間当たりのテクスチャユニット起用頻度が多くなるため,グラフィックスコアの動作クロックが同じで,グラフィックスメモリへの書き出し性能も同一だった場合,Single Texturingと比べて,テクスチャユニットの影響がより大きくなる。
名前の通り,ピクセルシェーダユニットの性能を見るためのテストだ。このテストはフレームレート(fps)で結果が算出される。
テストに用いられるのはSM3.0 Graphics Test 1の水棲怪物と飛行船のシーンで用いられた「岩壁」のシェーダ。頂点レベルでの光源処理をしたこの岩壁を画面全域に表示するもので,水面などは登場しない。なお,シェーダ設計そのものはプログラマブルシェーダ2.0(Shader Model 2.0,以下SM2.0)レベルのものになっており,SM2.0対応グラフィックスチップでも実行できるようになっている。もっといえば,このテスト自体は3DMark05のPixel Shaderテストと基本的にまったく同じである。
実行されるシェーダ設計そのものはSM2.0レベルのものになっており,SM2.0対応グラフィックスチップでも実行できる
岩壁シェーダは,法線ベクトルと光源ベクトルだけで演算する最も単純な拡散反射系の光源処理の一つである「ランバート拡散照明」をピクセル単位で処理する以外,3枚の画像テクスチャ(=デカールテクスチャ),3枚の法線マップによるバンプマッピング適用処理からなっている。ピクセルシェーダのテストとされていながら,「実はテクスチャアクセスの頻度が高い」とFuturemarkも資料の中で自虐的(?)に述べている。
テクスチャの枚数が多く,テクスチャキャッシュにも載りにくいランダム性の高い従属テクスチャ読み込みを多用するため,実テクスチャアクセス(=グラフィックスメモリへのアクセス)が頻発する。すると必然的に,テストにおけるグラフィックスメモリ帯域幅の影響は大きくなる――。
これについてFuturemarkは「実際のゲームも複数枚のデカールテクスチャや法線マップを適用するものが多いから,こういう形にした」と説明している。つまり,グラフィックスチップのピクセルシェーダ性能をテストするものではなく,「3Dゲームにおいてよく用いられるピクセルシェーダプログラムを,どの程度高速に実行できるか」を計測するものだといいたいわけだ。
いずれにせよ,「Pixel Shader」というテスト名の割には,テクスチャユニット数,グラフィックスメモリ速度といったテクスチャ性能の影響が大きいことは理解しておきたい。
頂点シェーダのテストの原型はDirectX 7世代のベンチマークテストである3DMark2000の「High polygon count」だ。これは,超多ポリゴンからなるメリーゴーランドにテクスチャなしで拡散反射や鏡面反射を適用してフレームレートを求めるテストで,テクスチャ性能を除いた,ジオメトリ性能とフィルレート性能を見るためのものだった。
DirectX 8世代の3DMark2001からは頂点シェーダの単体テストとして導入され,その後,姿形を変えながら現在に至っている。
3DMark06の頂点シェーダテストは3DMark05から持ち越されたSimple(簡素)とComplex(複雑)の2パターンが用意されており,いずれも結果は1秒間あたりに処理できた頂点の数,すなわち頂点毎秒(Vertices/s)で算出される。
●Simple
超多ポリゴンといえる約100万頂点からなる水棲怪物のモデルを4体(合計400万頂点)をテクスチャなしで表示し,回転させながら頂点単位のライティングを施すテストだ。
非常にシンプルな頂点シェーダプログラムが走ることになるので,メモリアクセス(=シェーダプログラムの命令フェッチや頂点データの読み出し)も最少限となり,頂点シェーダユニットの数やグラフィックスチップのコアクロックに依存した結果が出やすい。
|
|
モデル自体はSM3.0 Graphics Test 1の,水棲怪物の“多ポリゴンバージョン”を利用している |
●Complex
こちらは,膨大な数(数は非公開)の草を1本1本バラバラに,パラレルになびかせて揺らすテストだ。
CPUによって算出される,算術合成されたノイズ「フラクタルノイズ」を基にして,各草はそれぞれ違ったポーズにボーンを折り曲げられ,頂点シェーダプログラムによってその姿勢に合ったボーンスキニング処理がなされる。ボーンスキニング処理とは,ボーンの姿勢につじつまの合う形で,外皮に相当する3Dモデルを変形する処理系のこと。
フラクタルノイズの生成はCPUで行われるが,Futuremarkは,このCPU負荷は小さいとしている。
テストでは,草の生えたフィールドの全域がなるべく常時描かれるよう,やや視点が引いた構図になっているが,これはフィールド上の草すべてに対して実際に頂点シェーダプログラムの処理が実行されるようにするため。言い換えると,視点を近づけすぎて,草が画面外にクリップアウトしてしまうと,画面外にある草に対しては頂点シェーダプログラムの処理が省略されてしまうからだ。また,画面上のピクセル描画量をあまり変化させずに,頂点シェーダユニットの性能測定を行う狙いもある。
SimpleとComplexの違いを一言でまとめると,Simpleでは「単純頂点シェーダプログラム×大量頂点」というテストになっているのに対し,Complexは「長めの頂点シェーダプログラム×大量頂点」というテストになっている,といったところだ。Complexのほうが,負荷は当然高くなる。
テスト結果の傾向自体は,SimpleとComplexでほとんど同じになると思われるが,ドライバやコンパイラの進化でシェーダ命令の実行効率が向上した場合,その効果はComplexのほうに出やすい。