つぶやく
2013/06/01 00:00テストレポート
Frapsのフレームレートは正しくない？ NVIDIAが提案する新たなフレームレート計測ツール「FCAT」を試してみた
「Frapsで計測したフレームレートは必ずしも正しくない」。そんな話が飛び出せば多くの人は驚くだろう。4Gamer読者には釈迦に説法だが，Frapsは，PCにおける3Dグラフィックスのフレームレートを計測するツールとして事実上の標準ツール（の1つ）だからだ。4Gamerでもゲームアプリケーションのベンチマークで日常的に使っており，そんなFrapsによるフレームレート測定が正しくないとすれば，業界全体がひっくり返るくらいの騒ぎになりかねない。
では，そんなことを誰が言い出したのかというと，PC用GPUメーカー二大巨頭の一社，NVIDIAである。同社は，Frapsによる測定データに100％の信頼は置けないとして，新たなフレームレート測定ツール一式「Frame Capture Analysis Tool」（FCAT，エフキャット。以下略称表記）を自社で開発し，実際に，ドライバアップデート時や新製品発表時の「性能向上率」を示すのに使い始めているのだそうだ。
これは完全にNVIDIAの社内向けツールで，別にこれを一般ユーザーへ販売したりするつもりはないとのことだったが，公開されないツールとなれば，いったい何をしているのか気になるところだ。今回4Gamerでは，このNVIDIA社内向けツール一式を入手できたので，NVIDIAが何を言わんとしているのか，Frapsとの比較を通じ，「ゲームフレームレート計測」そのものを考察してみたい。
Frapsは，オーストラリアのBeepaが手がけるシェアウェアで，フレームレートの計測や，スクリーンショットおよびビデオの撮影機能も持つ……というのは今さら説明するまでもないだろう。だが，「そもそもFrapsがどのようにしてフレームレートの計測を行っているのか」となると，説明できる人はそう多くないのではなかろうか。
BeepaはFrapsのソースコードを公開していないが，DirectX APIの一部を横取り（※専門用語で言う「フック」）するという，一般的な手法を採用していることは容易に想像できる。理由は簡単で，ソフトウェア的にフレームレートを測る方法がほかにないためだ。Fraps以外のフレームレート計測ツールでも，DirectXの画面に任意の文字をオーバーレイさせる手法としてAPIを横取りする手法を使っているので，Frapsもそうだろう，というわけである。
ちなみにこの手法でよくあるのは「EndScene」や「Present」メソッドを横取りする方法だ。
もう少し噛み砕いて説明すると，DirectXを使うプログラム，たとえばゲームエンジンは，
という流れで1フレームを描画している。
ここで「Scene」（シーン）という言葉が出てくるが，これは3D業界の専門用語だ。DirectXでは「BeginSceneを呼び出し，それからEndSceneを呼び出すまでの間にゲームエンジンが実行するレンダリング処理によって描かれる画像」をSceneと呼んでいる。「1フレームの描画内容」イコールScene，という理解でいいだろう。
BeginScene〜EndSceneの間にレンダリングされる画像は，ディスプレイに表示されない「オフラインバッファ」上に展開されている。そしてゲームエンジンがPresentメソッドを呼び出すと，オフラインバッファから，実際に表示されるフレームバッファへと画像データをDirectXが転送する仕組みである。「画像を描いている途中経過」をプレイヤーが目にせずに済むのは，完成した画像が，フレームバッファにドンと送られるからだ。
さらに予備知識を続けると，ゲームのグラフィックス設定や3Dグラフィックスのプロパティに用意されている「垂直同期」を有効化にすると，「Presentメソッドの呼び出しに応じてDirectXが画像をフレームバッファへ転送するタイミング」が，垂直同期（リフレッシュレート）と合うようになる。
いずれにしても，EndSceneやPresentメソッドを横取りすれば，レンダリングが終わったタイミングや，1フレームを描き終えてフレームバッファに転送されたタイミングが分かる。したがって，EndSceneやPresentメソッドが1秒間に何回呼び出されたかを数えれば，フレームレートが分かるわけだ。
高速なGPUなら短時間でシーンの描画を行えるので，EndSceneメソッドやPresentメソッドが頻繁に呼び出され，結果，フレームレートは高くなる。そうでなければ低くなるというわけで，Frapsが採用している手法は一見すると理に叶っているように見える。
では，NVIDIAはFrapsの何を問題視しているのだろうか。それは「シーンの描画速度が一定ではない」点だ。
描画負荷の低いシーンだと描画自体を1msで終わらせられるかもしれない一方，描画負荷が高ければ描画し終えるまでに20msかかるかもしれない。シーンの描画負荷，俗にいう“重さ”によって，その違いは何十倍，何百倍にもなり得るわけだが，一方で現実のディスプレイに表示されるタイミングはリフレッシュレートに固定されている。
ディスプレイはリフレッシュレートに応じて画面を更新する。リフレッシュレートが60Hzならば，シーンの描画速度がどんなものであったとしても，ユーザーが目にする映像はあくまで1秒あたり60フレームになるのだ。つまり，シーンの描画速度と，ユーザーが目にする映像との間には大きなズレがある。NVIDIAが問題視しているのは，まさにその点なのである。
先ほども触れたように，ゲーム側，あるいはグラフィックスドライバ側で垂直同期を有効化すれば，シーンの描画速度とリフレッシュレートのタイミングが合うため，ユーザーが目にするフレームレートはシーンの描画速度とイコールになるが，Frapsでフレームレートを測るときには垂直同期を無効化しなければならない。理由は簡単で，EndSceneメソッドやPresentメソッドの回数を数えるFrapsの手法では，垂直同期を有効にすると，フレームレートの上限がリフレッシュレートで固定されるからだ。
しかし，垂直同期を無効化すれば，シーンの描画速度と，ユーザーが目にする映像との間にズレが生じる。では，垂直同期を無効化すると，ディスプレイに画面はどのように表示されるのだろうか。
リフレッシュレートを60Hzに設定したときを考えてみよう。GPU内部の映像出力回路は，約16.7msの一定間隔でフレームバッファをスキャンしてディスプレイ信号に変換し，ディスプレイへと送ることになるが，このとき垂直同期設定を無効化していると，映像出力回路がフレームバッファをスキャンしている最中にもフレームバッファの内容が更新される。
繰り返しになるが，要するにNVIDIAは，「Frapsで表示されるフレームレートとプレイヤーが目にするフレームは必ずしも一致しない」ことを指摘しているわけだ。
ただし，「Frapsで表示されるフレームレートとプレイヤーが目にするフレームが一致しないこと」それ自体は，実のところゲーマー的には問題にならない。というのも，ゲームをプレイするときに垂直同期を有効化すれば，プレイヤーが目にするフレームとレンダリングされているフレームは一致するからだ。つまり，問題になるのは「Frapsでフレームレートを測るとき」だけである。
では，Frapsでフレームレートを計測すると，具体的にどんな問題があるのか。それをNVIDIAは下の図のとおり示している。いわく，垂直同期を無効化すると，あるフレームがディスプレイに表示されなかったり（＝ドロップしたり），不完全に表示されてしまったりといったことが起こる場合があるという。
NVIDIAが主張するような現象がなぜ起こるのか断言はできないが，推測はできる。たとえば，「何らかの理由で正常にシーンのレンダリングが終えられなかった」というものだ。GPUやドライバのエラーにより，レンダリングが正常に終えられないまま，Presentメソッドが呼び出されてしまうケースである。
エラーなどにより，GPU側でレンダリングが最後まで実行されないと，BeginSceneからEndSceneまでの処理が超高速で終了することが起こりうる。そうなると，エラーが生じたフレームが表示されなかったり描画が不完全になったりする（がフレームとしては存在するので，Frapsで計測したときのフレームレートが上がってしまう）というわけだ。
また，「ゲームエンジン内の処理に問題があるために，レンダリングが不完全になる」ケースも考えられよう。ゲームのバグやゲームプログラム内部の時間管理に問題があり，レンダリングを途中でやめてしまう，というケースである。垂直同期の無効化によって，そのようなトラブルが顕在化するゲームプログラムがあるというのも，納得できる話である。
いずれにしても，APIの呼び出し回数を調べるFrapsは，ドロップしたり，正常に表示されていなかったりしたフレームもカウントしてしまう。それが問題だと，NVIDIAは指摘しているわけだ。
ようやく本題のFCATだ。これは，Frapsが以上のような問題を抱えることを受けて，NVIDIAが開発した測定システムである。同社によれば，数年前に完成し，社内でフレームレートを計測するときにはFCATを使ってきたという。
ではなぜこのタイミングでNVIDIAは存在を公表したのかというと，「ゲーマーと知識を分かち合うため」とのことだ。決して自社製品に有利なフレームレートを出すための装置ではないというわけである。
「『NVIDIA製』である以上，公正さはがあるとは到底思えない」と言う人もいそうだが，結論から先にいうと，FCAT自体に大した秘密や工作はなく，また，介在する余地もない。
FCATは簡単にいうと，実際にディスプレイ上で表示されているフレームを調べるためのシステムだ。仕組みは極めて単純で，ベンチマーク対象のPCから出力した映像を，別のPCに差した高性能ビデオキャプチャカードで非圧縮データのまま“録画”し，それを分析することで，「ドロップしたフレーム」や「不完全にしか表示されなかったフレーム」の存在を把握し，実際にユーザーが目にするフレームレートや，ドロップしたフレームや不完全なフレームの数を調べようというのである。
疑り深い人だと，「キャプチャカードがNVIDIA製なら，やろうと思えばなんでもできるだろ」と思うかもしれないが，FCATの指定キャプチャカードは英Detapathの業務用製品「VisionDVI-DL」であり，一般ユーザー向けではないものの，汎用品である。NVIDIAもDetapathから購入して使っているのだそうだ。
ちなみにDual-Link DVIスプリッタは，Gefen製の業務用製品「1：2 DVI DL Splitter」（型番：EXT-DVI-142DL）が指定されている。こちらは4Gamerで液晶ディスプレイのテストに用いているのと偶然にも同じものだったため，今回のテストではそのまま使い回すことにした。
Vision DVI-DLは何の変哲もないキャプチャカードだが，十分に高速なストレージに保存するという条件付きで，最大2560×1440ドット，垂直リフレッシュレート60Hzの映像をドロップなしに取り込める性能を持っている。つまり，テストできる解像度は2560×1440ドットが最大ということになるが，「NVIDIA Surround」，あるいはAMDの「Eyefinity」といったマルチディスプレイベースの擬似高解像度では，プライマリディスプレイ出力をVisionDVI-DLで取り込むことでテストが行えるようになっている。
なお，シングルディスプレイで解像度2560×1440ドット，垂直リフレッシュレート60Hzを超える解像度を取り込んでFCATシステムで分析するには，VisionDVI-DL以上の性能を持つキャプチャカードが必要になるとのことだった。
ところで，当然ながら取り込んだビデオデータをただ調べても，ドロップしたフレームや不完全にしか表示されないフレームは分からない。そこでNVIDIAはFCATのベンチマーク対象機側で「Overlay」（オーバーレイ）という名のツールを動作させることになる。
このOverlayも別に特殊なものではなく，画面の左側にカラーバーをオーバーレイ表示させるだけのツールだ。DirectX APIを横取りして，フレームごとに異なる色のバーをオーバーレイ表示させる仕組みになっている。Frapsだと，カウントしたフレームをフレームレートとして画面の4隅へ表示させるところを，フレームごとに異なる色のカラーバーを表示させるようにしただけで，やっていることはFrapsと大差ない。
下に示したビデオは，Overlayを常駐させた状態でゲームを実行し，それをカシオ製のハイスピードカメラ「HIGH SPEED EXILIM EX-FH100」から，標準的なディスプレイのリフレッシュレート比で4倍速となる240fps設定で撮影したものだ。通常速度で撮影してしまうと，左側のカラーバーがチラチラして何が何だかわからないため，4倍速で撮影したものを標準速で再生しているわけである。
で，ビデオを見ると，グラフィックスレンダリングのほうがリフレッシュレートより高速なため，1つの画面の中に複数のフレームが存在し，そのため，Overlayによって重ねられたカラーバーも1画面の中に複数の色が存在することが確認できるだろう。
表示されるカラーバーの色は全16色。16フレームで色は一周する。なので，フレームのドロップが連続するとしても，連続16フレーム以上のドロップがない限りは，ドロップしたフレームが分かるわけだ。連続16フレームものドロップが発生することはまず考えられないので，この仕様で問題はないだろう。
さて，この「カラーバー入りゲーム映像」を，ベンチマーク対象のPCから出力し，スプリッタ経由で分割し，VisionDVI-DLでPCにビデオデータとして取り込むことになるわけだが，取り込みには，オープンソースのフリーソフトウェア「VirtualDub」（ヴァーチャルダブ）を使うよう指示されている。
非圧縮AVI形式で取り込んだ各フレームを分析するため，形式は細かく規定されているのだが，枝葉末節なので詳細は省く。基本的には「60fpsでドロップなしに非圧縮AVI形式で取り込む」よう指定されていると考えてもらえばいい。
取り込んだデータは，FCAT用にNVIDIAが介したツール「Extractor」（エクストラクタ）で読み出す。これは，フレームごとにカラーバーを分析し，統計データとして出力するものだ。
さらに，Extractorが出力した統計データを（NVIDIA製の）Perlスクリプト――メインの「fcat.pl」と，3本のユーティリティスクリプトで構成されている――で処理することで，「フレームレートの推移」や，「ドロップおよび不完全なフレームが含まれる割合」といった，人間が見て分かりやすい表やグラフに変換する。
ちなみにここで用いるグラフ化アプリケーションは「gnuplot」（グニュプロット）で，これもオープンソースである。
以上がFCATの概要だが，ではFCATでどのようなデータが得られるのだろうか。続くテストパートでは，データの意味を説明しつつ，いくつか，実際のゲームアプリケーションを用いてテストしてみよう。
NVIDIAはFrapsで計測するフレームレートが必ずしも正しいとは限らないと指摘しているわけだが，4GamerでGPUの検証に用いているベンチマークレギュレーションだと，5月下旬時点の最新版となるバージョン14.0で，下記4タイトルでFrapsを用いた計測に頼っている。
これら以外のタイトルは，Frapsを使わず，独自のベンチマークスコアを出してくるタイトルになる。詳しくは後で触れるが，独自のベンチマークスコアを出してくるタイトルでも，前節で指摘したのと同じ問題を抱えていたりするわけだが，NVIDIAはFrapsの信頼性が必ずしも100％とは言えないと主張しているので，今回はFrapsを使う上記の4タイトルに絞ってFCATによる検証を行うことにした次第である。
今回用意したグラフィックスカードは2枚。1つは「GeForce GTX 680」のリファレンスカード（以下，GTX 680）で，もう1つは，Sapphire Technology製の「Radeon HD 7970 GHz Edition」を搭載したリファレンスクロック採用モデル「VAPOR-X HD7970 GHZ EDITION 3G GDDR5 PCI-E」（以下，HD 7970 GE）だ。
テストに用いたグラフィックスドライバは，いずれもテスト開始時点の最新版で，具体的にはGTX 680用が「GeForce 320.18 Driver」で，HD 7970 GeForce GTX 650 Ti BOOSTが「Catalyst 13.5 Beta2」だ。Radeon用にはテスト開始後に「Catalyst 13.6 beta」も登場しているが，今回テストするゲームに向けた最適化やバグフィックスはアップデート内容に含まれていないため，最新ドライバを用いていないことの影響は無視できるレベルだと考えている。
そのほかベンチマーク用に用いたPCの構成は表1のとおり。テスト解像度は1920×1080ドットおよび2560×1440ドットとし，4xアンチエイリアシングと16x異方性フィルタリングを適用した「高負荷設定」（※The Elder Scrolls V: Skyrimだと，4xではなく8xアンチエイリアシングを適用した「Ultra設定」，SimCityではアンチエイリアシングを有効化した「AA＆AF有効化設定」）でテストを行う。
なお，CPUの「Core i7-3770K/3.5GHz」は，秋葉原のPC＆PCパーツショップであるパソコンショップ アークの協力を得て入手したものである。4GamerのGPUレビュー時と同じく，CPUの自動クロックアップ機能「Intel Turbo Boost Technology」は，テスト状況による効果の違いが生じる可能性を排除すべく無効化した。
ベンチマーク用のPCからDVIスプリッタ経由でビデオ信号をVisionDVI-DLへ入力するにあたっては，表2に示した構成のPCを用いた。
VisionDVI-DLを動かすキャプチャ用PCでは，「ストレージが高速でさえあればどんなものでもいい」「RAID 0は必須」というアドバイスがあったため，容量256GB版のSamsung Electronics製SSD「SSD 840 PRO」を（前出のCPUと同様に）パソコンショップ アークの協力で2台入手している。2台はASUSTeK Computer製の「Intel Z77 Express」チップセット搭載マザーボード「Maximus IV Extreme-Z」でチップセットによってサポートされるSerial ATA 6Gbpsに差し，RAID 0で構成してキャプチャデータ保存用に使うことにした次第だ。
では，タイトル順に見ていくことにしたい。テストはCrysis 3から始めたので，Crysis 3を最初に取り上げ，かつ，スコアの見方などもここで重点的に説明していくことをあらかじめお断りしておきたい。
というわけでCrysis 3だ。ベンチマークレギュレーション14.0では，Frapsで計測時間を60秒に指定したうえで，実際にゲームプレイを行うことが規定されているが，FCATでは「スタートからn秒間を自動的に計測」といったオプションは用意されていない。そのため，ビデオのキャプチャ開始と停止は手動で行わなければならず，「60秒きっかり」というわけにはいかない。とくにCrysis 3の場合は，テストにあたって実際にゲームをプレイしなければならないので，Frapsと比べると測定時間が5〜10秒程度は長くなると考えてほしい。
また前述のとおり，グラフはNVIDIAのスクリプトとgnuplotによって生成される都合上，4Gamerのハードウェア検証記事で見慣れた形式にはならない。この点もあらかじめご了承のほどを。
さて，4Gamer読者が最も気になるのは，「NVIDIAの言う『ドロップしたフレーム』や『不完全なフレーム』がどの程度あるのか」だろう。それを示すものが次に示すグラフだ。
グラフは横軸が経過時間（秒），縦軸がフレームレート。つまり，フレームレートの時間変化を表すグラフということになる。上がGTX 680，下がHD 7970 GEで，いずれも1920×1080ドット解像度のスコアとなる。
グラフの凡例にもあるとおり，Frapsによる計測データは黒い線で示される。ただし，「本物の」Frapsを使って測定したフレームレートではない。グラフ上に黒い線で示されるのは，「Overlayによってオーバーレイされたカラーバーのカラーを使ってカウントした，“Frapsと同等の”フレームレート」という意味である。
OverlayはFrapsと同様にDirectX APIを横取りしてカラーバーをオーバーレイさせているので，カラーバーの色を調べればFrapsが出すフレームレートと同じ値が分かる，というわけだ。
さらに，ドロップしたり不完全だったりしたフレームを差し引いたFrapsのフレームレートから差し引いたフレームレート――NVIDIAはこれを「Native FPS」（NFPS）と呼んでいるが，凡例には「FPS」としか書かれていない――は青い線で描かれる。
……のだが，ここでは黒い線の上に青い線が完全に重なっているため，黒い線は見えない。要するに，Native FPSとFrapsの測定データは一致しており，ドロップしたり不完全だったりするフレームはなかったという意味になる。今回のテスト条件だと，Frapsで取得したスコアに疑う余地はない，とも換言できるわけだ。
では，解像度2560×1440ドットではどうだろうか。その結果をまとめたのが次のグラフで，ここでもNative FPSと“Frapsの測定データ”は一致している。「1920×1080ドットと2560×1440ドットの高負荷設定，かつシングルカード構成において」という条件付きにはなるが，Frapsのデータはほぼ信頼していいと見ていいのではなかろうか。
ちなみにFCATでは，さらに2つ，面白いグラフが得られる。1つは「パーセンタイル」，もう1つは「フレームタイム」だ。
パーセンタイル（percentile，分位点）というのは聞き慣れない言葉だと思うが，簡単に説明すると，データ（※FCATにおいてはフレームレート）がどのようにバラ付いているかを読み取れるものとなっている。
次に示すグラフがパーセンタイルのデータをまとめたものだ。先に述べたとおり，きっちり1分（3600フレーム）とはいかないが，おおむね3600フレームとして，3600個あるフレームレートが全体の中でどれくらいの割合を占めるのかがこのグラフから読み取れるようになっている。
グラフ縦軸は最小フレームレート，横軸はパーセンテージなので，この例なら，グラフ縦軸で20のラインをたどると，GTX 680においては約80パーセンタイルのところにある。よって「GTX 680におけるフレームレートの80％は20fps以上」と言える，といった具合である。
最小フレームレートを大きく取るほど該当データの数が減るので，何か変なことがない限り，グラフは右肩下がりになる。一方，グラフの右端では最小フレームレート付近のバラツキが見える。つまり，グラフの形からGPUの特性というか，フレームレートのバラツキ方の違いが見えてくるわけだ。もっとも，ここでは比較対象の2製品に大きな違いはないのだが。
なお，上で示したのは解像度2560×1440ドット時のものだが，1920×1080ドットでも大きな違いはなかったことを付記しておきたい。
もう1つのフレームタイムをまとめたものが下のグラフだ。ここでは横軸が経過時間，縦軸が当該フレームを描画するのに要した時間」を示す。つまりは，フレームの描画時間がどのように変化するかを追ったものということになる。
ここではGTX 680もHD 7970 GEも基本的に一定の範囲で帯状のグラフになっているが，これはフレームの描画時間に相応の変動が生じているという意味になる。一部でところどころ跳ね上がっているのは，何らかの理由により，当該フレームを描くのに，例外的に長く時間がかかったものというわけだ。
FCATが生成するグラフの意味をざっくりと把握したところで，ここからは主にフレームレートの推移を見るグラフを取り上げ，面白い特徴があるデータではパーセンタイルのグラフも示すという形で進めていくことにしたい。
というわけでFar Cry 3である。本タイトルでも，レギュレーション14.0では1分間のフレームレートを計測することになる。Crysis 3と異なり，テストにあたってユーザー操作は不要なので，Frapsとの測定時間誤差はCrysis 3のときほど大きくはならないが，それでも数秒程度の誤差が出ている点はあらかじめお断りしておきたい。
フレームレートの推移は下にまとめたとおりで，1920×1080ドットと2560×1440ドット，どちらの条件でも，FCATとFrapsの測定データは一致した。掲載は見送るが，パーセンタイルといフレームタイムもGTX 680とHD 7970 GEの間で大きな違いはなし。つまり，Crysis 3と同様，FCATならではというデータは取れなかった（＝Frapsのテスト結果に信頼が置ける）タイトルということになる。
いきなりテスト開始から2タイトル連続でFCATとFrapsで大きな違いがなかったわけだが，The Elder Scrolls V: Skyrim（以下，Skyrim）ではついに違いが生じた。
すでに述べたように，FCATは動画をキャプチャし，Extractorで統計データを出し，スクリプトで処理するという手順をとる。そして，Skyrimでも正常な動画はキャプチャでき，VirtualDubを使った検査ではビデオにドロップがないことも確認できているのだが，最後にスクリプトで処理しようとすると，「ドロップしたフレームがある」というエラーが発生してしまうことがあるのだ。
くどいほど何度もやり直したのだが，GTX 680では最後まで2560×1440ドット解像度のデータを取ることができなかった。そのため今回は当該データを割愛する。データを取得できなかった原因は不明だが，何か分かったらあらためてお伝えしたいと思う。
なお，Skyrimのテストもベンチマークレギュレーション14.0準拠。先の2タイトル同様，測定時間には手動操作によるばらつきがある。
さて，そういうわけで，今回はGTX 680とHD 7970 GEを問題なく比較できる1920×1080ドットでSkyrimのスコアを見ていこう。
まずはGTX 680からだが，46秒と50秒のところで，青い線と黒い線の乖離を確認できる。このグラフだけだと読み取れないが，統計データを調べると，GTX 680では合計3フレームのRunt Frameが生じたことが分かった。本稿の序盤でも触れたように，Runt Frameは20ライン以下しか描画されなかった不完全なフレームのことだ。なお，ドロップしたフレームはゼロである。
一方のHD 7970 GEでは，テスト開始直後の3〜5秒後に，青い線と黒い線の大きな乖離を確認できた。また，15秒，35秒，46秒にも小さな乖離が見られる。
なお統計データによると，テスト合計で不完全なフレームが12あり，ドロップはゼロだった。
要するに，Skyrimの1920×1080ドット・Ultra設定では，Runt Frameとされた不完全なフレームが存在し，これを差し引くと，Frapsで得られるスコアよりも，実際のフレームレートはやや低くなるというわけだ。ただ，その違いは誤差範囲といっていい程度でもある。
というのは，FCATで得られるCSV形式の統計データで，FrapsのフレームレートとNative FPSを知ることができるためだ。ここで示した画面はまさにSkyrimのものだが，不完全なフレーム数はごく少なく，フレームレートに大きな影響を与えるものではなかった。
Skyrimでは，GTX 680とHD 7970 GEのパーセンタイルにも有意な差が現れた。それが下のグラフだが，グラフの形状に大きな違いがあることは一目で分かるだろう。GTX 680ではほどよいバラツキになっていて，フレームレートの変動幅が大きくないのに対し，HD 7970 GEでは，少ないサンプル数ながら極端に高いフレームレートが記録されている。
極端に高いフレームレートが記録される一方で，グラフ右肩はGTX 680より低いというのは，低いフレームレートも多く混ざっているということを意味している。つまりHD 7970 GEのほうがフレームレートの変動幅が大きく，描画が安定していないことを窺わせる結果になっているのである。
前述のとおり，2560×1440ドット解像度では，HD 7970 GEでしかスコアが取れなかったが，フレームレートは露骨に分かりやすいデータとなった
青い線と黒い線の間を，橙と赤がまんべんなく埋めており，不完全なフレームの発生とフレームのドロップが全体にわたって生じていたことが分かる。統計データによると，不完全なフレームは232，ドロップしたフレームは137あった。
Frapsの計測値は84.62fpsになるが，不完全なフレームやドロップしたフレームを差し引いたNative FPSは77.24fpsと，かなり大きな開きがあることも統計データで示されている。
残念ながら，GTX 680との比較ができないため，不完全なフレームやドロップしたフレームが多かった理由は推測できないが，GTX 680やHD 7970 GEといったハイエンドクラスのGPUにとって，Skyrimの描画負荷が低いのが原因かもしれない。HD 7970 GEで，フレームレートのばらつきが非常に大きくなっていることから，60Hzで映像を送り出すときに表示されるフレームが安定しないというというのは大いに考えられるだろう。
SimCityは，ベンチマークレギュレーション14だと120秒間の計測が規定されているのだが，FCATで120秒間の計測を行うと非圧縮のキャプチャデータが極めて大きくなり，ときとして空き容量が厳しくなることから，今回はテスト開始から（約）60秒間のデータで留めることにした。
計測時間以外はレギュレーション準拠である。
解像度1920×1080ドット時のスコアは次に並べて示したとおり。HD 7970 GEで開始8秒後に若干の乖離が見られるほかは安定している。
一方の2560×1440ドットでは，テスト対象となる2製品のどちらでもまんべんなく不完全なフレームが生じ，HD 7970 GEでは一部でフレームのドロップも生じたことが分かる。GPUに関わらず同じような傾向が出ているので，まんべんなく生じている不完全なフレームは，ゲームタイトルの特性とみるべきだろう。実際，パーセンタイルやフレームタイムに特徴的な違いはなかった。
ちなみに，統計データによれば，2560×1440ドット解像度における不完全なフレームの数はGTX 680が225，HD 7970 GEが248。ドロップはGTX 680が0，HD 7970 GEが17だった。
そのため，Frapsの計測値とNative FPSとの間にはもちろん開きが生じており，GTX 680ではFrapsが63.94fpsに対してNative FPSは59.53fps，HD 7970 GEではFrapsが72.06fps，Native FPSが66.96fpsで，約7％の開きがあった。
つまり，SimCityの2560×1440ドットだと，ユーザー体験的にはFrapsから7％ほど低いフレームレートになるということだろう。
続いてはマルチGPU構成のテストだ。ここからは，表1のシステムに，もう1枚のGTX 680のリファレンスカード，もしくは追加のHD 7970 GEリファレンスカードを足して，SLIあるいはCrossFire構成を構築したうえでテストを行っていく。グラフィックスカードの構成以外は何も変更していない。
ただし，テストに用いるタイトルはCrysis 3とFar Cry 3に絞る。Skyrimではシングルカード構成時にもあった「測定データが安定しない」問題がSLI動作時に悪化したこと，SimCityはそもそもマルチGPU構成でフレームレートの向上を期待できないことがその理由である。
では，またCrysis 3から見ていこう。
Crysis 3のマルチGPU構成では1920×1080ドットにおいて非常に興味深いデータが得られた。
下に示した2本のグラフを見ると，異常が生じているのはHD 7970のCrossFireだというのはすぐに分かるだろう。不完全，もしくはドロップしたフレームの数が異常に多いのだ。
ただ，測定をミスしている可能性は極めて低い。というのも，NVIDIAでも内部で4Gamerの測定結果に近いデータを持っていることが示唆されたためである。FCATを公開した理由を「ゲーマーと知識を共有したいから」と述べているNVIDIAだが，もしかすると，マルチGPU構成時の結果を見せて，「ゲーマーと（SLIとCrossFireではこんなに違うという）知識を共有したい」のではないかという気もしてくる。
いずれにしても，HD 7970 GEのCrossFire構成だと，Frapsで得られる平均フレームレートとNative FPSの違いも極めて大きい。GTX 680 SLIの場合，Frapsのスコアが57.15fps，Native FPSが57.05で，違いは0.2％もないのだが，HD 7970 GEのCrossFireだとFrapsのスコアが93.32fpsのところ，Native FPSはなんと45.05fps。約48.3％しか出ていないのである。
なぜこのような結果になるのか推測するのは難しいが，これほど極端な“症状”だと，先に述べたようなGPUやドライバのエラーも疑える。実際，パーセンタイルを見てみると，HD 7970 GEのCrossFireでは極端に高いフレームレートが計測されるなど，バラツキが非常に大きい。これは何らかの問題が生じている結果かもしれない。
さらに疑り深い見方をするなら，AMDのグラフィックスドライバが部分的にシーンの描画を端折っているということもあり得なくはない。というのは，解像度を高くしてグラフィックス描画負荷を引き上げると，下にグラフで結果を示したとおり，HD 7970 GE CrossFireの持つ症状はぴたりと治まってしまうためだ。
もちろん，だからといって「AMDが特定の解像度に対して強引な最適化を行っている」と断言できるものではないのだが，「解像度を変えるといきなり問題がなくなる」というのが不自然なのも，また確かである。
Far Cry 3も1920×1080ドットからだ。
GTX 680のSLIでは合計4フレームの不完全なフレームが見られた。一方，HD 7970 GEのCrossFireではドロップしたフレームがやや多く，合計45に及んだ。また，不完全なフレームは19だった。そのため，Native FPSはHD 7970 GE CrossFireのほうがやや低めに出る。
これが2560×1440ドットだとどうなるかだが，いずれのマルチGPU構成においても，不完全なフレームやドロップするフレームが増える傾向が見られた。GTX 680 SLIだと不完全なフレームが185，ドロップが0。HD 7970 GE CrossFireだと順に325，63となっている。
その結果，Frapsの測定結果と比べると，GTX 680 SLIのNative FPSは約6％，HD 7970 GE CrossFireのNative FPSだと約14.5％低く出ている。Crysis 3のような不信な挙動はないため，ユーザー体験的なフレームレートを探るときは，この低下率がひとつの目安になりそうだ。
以上，FCATを試してきたが，興味深いデータが得られた，というのが率直な感想だ。Crysis 3を前にしたときの，マルチGPU構成における結果を見せつけられたりすると，NVIDIAがFrapsの測定結果に疑問を呈するのも無理はない印象を受ける。
4Gamerの読者の中にも，Frapsで高いフレームレートが記録できているのに，体感だとあまりフレームレートが高いとは思えないという経験をしている人がいるかもしれない。4Gamerのベンチマークレギュレーションでは，そういう状況を踏まえ，合格点となるフレームレートを高めに設定したりすることで対策しているわけだが，そういった「Frapsと体感とのギャップ」が，不完全なフレームやドロップしたフレームによるものだと考えることは十分に可能だろう。
たとえば，SimCityにおける高負荷環境のように，GPUの違いに関係なく，“安定して”不完全なフレームやドロップしたフレームが見られるタイトルなら，FCATのデータは参考になると思われる。Frapsの測定値から7％さし引いた程度が体感的なフレームレートになると考えられるからだ。
だが，特定のGPUのマルチGPU構成といったピンポイントの条件で不完全なフレームやドロップしているフレームが多発するケースも生じ得るということが，今回のテスト結果からは分かる。そして，そういった特定条件で発生する不完全フレームやドロップしたフレームは，FCATを用いて丹念に調べるしか知る方法がない。
「なら，4Gamerの普段のテストでもFCATを使えばいいのではないか」という議論は出てくると思うが，結論からいうと，そう簡単な話にはならない。機材の問題はさておくとしても，その手間を考えると，スピードが要求されるWebメディアの常用に堪えるものではないと結論付けざるを得ないからである。
ただ，FCATで非常に興味深い結果が得られ，またユーザーとしても参考になる結果が出ているのは確かだろう。今後，ベンチマークレギュレーションのアップデート時にFCATを利用することで，よりレギュレーションの精度は上げられるかもしれない。これは4Gamerとしての検討課題となりそうだ。
また，今回はテストを割愛したが，3DMarkのようなソフトウェアでフレームレートを計測するベンチマークスイートでも，不完全なフレームやドロップしたフレームが多発している可能性は十分にある。ソフトウェア的に「ユーザーが目にするフレームの数」調べる方法は筆者が考えられる限りでは存在しないため，Frapsを使わずにスコアを求める3DMarkのようなテストでも面白い結果が得られる可能性はあるだろう。
冒頭でも紹介したとおり，NVIDIAはFCATをパッケージ化して販売したりする計画はないとしている。そのため，エンドユーザーが試す機会はないと思われるが，NVIDIAがベンチマークのグラフを出してきたら，本稿でここまで語ってきた内容のようなテストを行っているのだと思い出すと，スコアの見方が変わってくるかもしれない。
 |
これは完全にNVIDIAの社内向けツールで，別にこれを一般ユーザーへ販売したりするつもりはないとのことだったが，公開されないツールとなれば，いったい何をしているのか気になるところだ。今回4Gamerでは，このNVIDIA社内向けツール一式を入手できたので，NVIDIAが何を言わんとしているのか，Frapsとの比較を通じ，「ゲームフレームレート計測」そのものを考察してみたい。
「Frapsはどのようにしてフレームレートを測っているのか」と，その落とし穴
 |
BeepaはFrapsのソースコードを公開していないが，DirectX APIの一部を横取り（※専門用語で言う「フック」）するという，一般的な手法を採用していることは容易に想像できる。理由は簡単で，ソフトウェア的にフレームレートを測る方法がほかにないためだ。Fraps以外のフレームレート計測ツールでも，DirectXの画面に任意の文字をオーバーレイさせる手法としてAPIを横取りする手法を使っているので，Frapsもそうだろう，というわけである。
ちなみにこの手法でよくあるのは「EndScene」や「Present」メソッドを横取りする方法だ。
もう少し噛み砕いて説明すると，DirectXを使うプログラム，たとえばゲームエンジンは，
- 「BeginScene」メソッドを呼び出してレンダリングを開始し，
- DirectX APIを使って1フレームのレンダリング処理を行い，
- 「EndScene」メソッドを呼び出してレンダリング処理終了をDirectXに通知し，
- Presentメソッドを呼び出してフレームバッファにシーンを送る
という流れで1フレームを描画している。
ここで「Scene」（シーン）という言葉が出てくるが，これは3D業界の専門用語だ。DirectXでは「BeginSceneを呼び出し，それからEndSceneを呼び出すまでの間にゲームエンジンが実行するレンダリング処理によって描かれる画像」をSceneと呼んでいる。「1フレームの描画内容」イコールScene，という理解でいいだろう。
BeginScene〜EndSceneの間にレンダリングされる画像は，ディスプレイに表示されない「オフラインバッファ」上に展開されている。そしてゲームエンジンがPresentメソッドを呼び出すと，オフラインバッファから，実際に表示されるフレームバッファへと画像データをDirectXが転送する仕組みである。「画像を描いている途中経過」をプレイヤーが目にせずに済むのは，完成した画像が，フレームバッファにドンと送られるからだ。
さらに予備知識を続けると，ゲームのグラフィックス設定や3Dグラフィックスのプロパティに用意されている「垂直同期」を有効化にすると，「Presentメソッドの呼び出しに応じてDirectXが画像をフレームバッファへ転送するタイミング」が，垂直同期（リフレッシュレート）と合うようになる。
いずれにしても，EndSceneやPresentメソッドを横取りすれば，レンダリングが終わったタイミングや，1フレームを描き終えてフレームバッファに転送されたタイミングが分かる。したがって，EndSceneやPresentメソッドが1秒間に何回呼び出されたかを数えれば，フレームレートが分かるわけだ。
高速なGPUなら短時間でシーンの描画を行えるので，EndSceneメソッドやPresentメソッドが頻繁に呼び出され，結果，フレームレートは高くなる。そうでなければ低くなるというわけで，Frapsが採用している手法は一見すると理に叶っているように見える。
 |
描画負荷の低いシーンだと描画自体を1msで終わらせられるかもしれない一方，描画負荷が高ければ描画し終えるまでに20msかかるかもしれない。シーンの描画負荷，俗にいう“重さ”によって，その違いは何十倍，何百倍にもなり得るわけだが，一方で現実のディスプレイに表示されるタイミングはリフレッシュレートに固定されている。
ディスプレイはリフレッシュレートに応じて画面を更新する。リフレッシュレートが60Hzならば，シーンの描画速度がどんなものであったとしても，ユーザーが目にする映像はあくまで1秒あたり60フレームになるのだ。つまり，シーンの描画速度と，ユーザーが目にする映像との間には大きなズレがある。NVIDIAが問題視しているのは，まさにその点なのである。
先ほども触れたように，ゲーム側，あるいはグラフィックスドライバ側で垂直同期を有効化すれば，シーンの描画速度とリフレッシュレートのタイミングが合うため，ユーザーが目にするフレームレートはシーンの描画速度とイコールになるが，Frapsでフレームレートを測るときには垂直同期を無効化しなければならない。理由は簡単で，EndSceneメソッドやPresentメソッドの回数を数えるFrapsの手法では，垂直同期を有効にすると，フレームレートの上限がリフレッシュレートで固定されるからだ。
しかし，垂直同期を無効化すれば，シーンの描画速度と，ユーザーが目にする映像との間にズレが生じる。では，垂直同期を無効化すると，ディスプレイに画面はどのように表示されるのだろうか。
リフレッシュレートを60Hzに設定したときを考えてみよう。GPU内部の映像出力回路は，約16.7msの一定間隔でフレームバッファをスキャンしてディスプレイ信号に変換し，ディスプレイへと送ることになるが，このとき垂直同期設定を無効化していると，映像出力回路がフレームバッファをスキャンしている最中にもフレームバッファの内容が更新される。
 |
繰り返しになるが，要するにNVIDIAは，「Frapsで表示されるフレームレートとプレイヤーが目にするフレームは必ずしも一致しない」ことを指摘しているわけだ。
ただし，「Frapsで表示されるフレームレートとプレイヤーが目にするフレームが一致しないこと」それ自体は，実のところゲーマー的には問題にならない。というのも，ゲームをプレイするときに垂直同期を有効化すれば，プレイヤーが目にするフレームとレンダリングされているフレームは一致するからだ。つまり，問題になるのは「Frapsでフレームレートを測るとき」だけである。
 |
では，Frapsでフレームレートを計測すると，具体的にどんな問題があるのか。それをNVIDIAは下の図のとおり示している。いわく，垂直同期を無効化すると，あるフレームがディスプレイに表示されなかったり（＝ドロップしたり），不完全に表示されてしまったりといったことが起こる場合があるという。
 |
| フレームの描画が順調に一定時間で実行されているときに，ユーザーが目にするフレーム。高速なGPUだと，たいていの場合は垂直同期より高速にフレームを描画するので，Frapsでカウントされる複数のフレームが1つの画面に収まる形になる。従って，欠落しているフレームはない |
 |
| GPU性能があまり高くなかったり，そのほかの理由でフレームの描画に時間がかかったりすると，ドロップするフレームが現れる。この図では，画面で目にする最初のフレームの次のフレームがドロップした。しかし，ゲームエンジン側でEndSceneやPresentメソッドは呼び出されているので，Frapsではドロップしたフレームもフレームとしてカウントすることになる |
 |
| ドロップするのと同じような理由で，あるフレームがほとんど表示されないということも起こり得る。NVIDIAの資料では20ライン以下にしか表示されないフレームを「Runt Frame」と呼んでいる。Runtは「取るに足らないほど小さい」という意味だが，本稿では「不完全なフレーム」とするが，このようなフレームもFrapsではカウント対象となる |
NVIDIAが主張するような現象がなぜ起こるのか断言はできないが，推測はできる。たとえば，「何らかの理由で正常にシーンのレンダリングが終えられなかった」というものだ。GPUやドライバのエラーにより，レンダリングが正常に終えられないまま，Presentメソッドが呼び出されてしまうケースである。
エラーなどにより，GPU側でレンダリングが最後まで実行されないと，Begin
また，「ゲームエンジン内の処理に問題があるために，レンダリングが不完全になる」ケースも考えられよう。ゲームのバグやゲームプログラム内部の時間管理に問題があり，レンダリングを途中でやめてしまう，というケースである。垂直同期の無効化によって，そのようなトラブルが顕在化するゲームプログラムがあるというのも，納得できる話である。
いずれにしても，APIの呼び出し回数を調べるFrapsは，ドロップしたり，正常に表示されていなかったりしたフレームもカウントしてしまう。それが問題だと，NVIDIAは指摘しているわけだ。
「ディスプレイに表示されているフレーム」を調べられるFCAT
ようやく本題のFCATだ。これは，Frapsが以上のような問題を抱えることを受けて，NVIDIAが開発した測定システムである。同社によれば，数年前に完成し，社内でフレームレートを計測するときにはFCATを使ってきたという。
ではなぜこのタイミングでNVIDIAは存在を公表したのかというと，「ゲーマーと知識を分かち合うため」とのことだ。決して自社製品に有利なフレームレートを出すための装置ではないというわけである。
「『NVIDIA製』である以上，公正さはがあるとは到底思えない」と言う人もいそうだが，結論から先にいうと，FCAT自体に大した秘密や工作はなく，また，介在する余地もない。
FCATは簡単にいうと，実際にディスプレイ上で表示されているフレームを調べるためのシステムだ。仕組みは極めて単純で，ベンチマーク対象のPCから出力した映像を，別のPCに差した高性能ビデオキャプチャカードで非圧縮データのまま“録画”し，それを分析することで，「ドロップしたフレーム」や「不完全にしか表示されなかったフレーム」の存在を把握し，実際にユーザーが目にするフレームレートや，ドロップしたフレームや不完全なフレームの数を調べようというのである。
 |
 |
| NVIDIAから貸し出しを受けたVisionDVI-DL。PCI Express x4接続で，Dual-Link DVI-D入力を持つカードである →Detapathの製品情報ページ（英語） |
 |
| Gefen製のDual-Link DVIスプリッタ。今回は4Gamerで所持している個体を用いる |
ちなみにDual-Link DVIスプリッタは，Gefen製の業務用製品「1：2 DVI DL Splitter」（型番：EXT-DVI-142DL）が指定されている。こちらは4Gamerで液晶ディスプレイのテストに用いているのと偶然にも同じものだったため，今回のテストではそのまま使い回すことにした。
Vision DVI-DLは何の変哲もないキャプチャカードだが，十分に高速なストレージに保存するという条件付きで，最大2560×1440ドット，垂直リフレッシュレート60Hzの映像をドロップなしに取り込める性能を持っている。つまり，テストできる解像度は2560×1440ドットが最大ということになるが，「NVIDIA Surround」，あるいはAMDの「Eyefinity」といったマルチディスプレイベースの擬似高解像度では，プライマリディスプレイ出力をVisionDVI-DLで取り込むことでテストが行えるようになっている。
なお，シングルディスプレイで解像度2560×1440ドット，垂直リフレッシュレート60Hzを超える解像度を取り込んでFCATシステムで分析するには，VisionDVI-DL以上の性能を持つキャプチャカードが必要になるとのことだった。
ところで，当然ながら取り込んだビデオデータをただ調べても，ドロップしたフレームや不完全にしか表示されないフレームは分からない。そこでNVIDIAはFCATのベンチマーク対象機側で「Overlay」（オーバーレイ）という名のツールを動作させることになる。
 |
下に示したビデオは，Overlayを常駐させた状態でゲームを実行し，それをカシオ製のハイスピードカメラ「HIGH SPEED EXILIM EX-FH100」から，標準的なディスプレイのリフレッシュレート比で4倍速となる240fps設定で撮影したものだ。通常速度で撮影してしまうと，左側のカラーバーがチラチラして何が何だかわからないため，4倍速で撮影したものを標準速で再生しているわけである。
で，ビデオを見ると，グラフィックスレンダリングのほうがリフレッシュレートより高速なため，1つの画面の中に複数のフレームが存在し，そのため，Overlayによって重ねられたカラーバーも1画面の中に複数の色が存在することが確認できるだろう。
表示されるカラーバーの色は全16色。16フレームで色は一周する。なので，フレームのドロップが連続するとしても，連続16フレーム以上のドロップがない限りは，ドロップしたフレームが分かるわけだ。連続16フレームものドロップが発生することはまず考えられないので，この仕様で問題はないだろう。
さて，この「カラーバー入りゲーム映像」を，ベンチマーク対象のPCから出力し，スプリッタ経由で分割し，VisionDVI-DLでPCにビデオデータとして取り込むことになるわけだが，取り込みには，オープンソースのフリーソフトウェア「VirtualDub」（ヴァーチャルダブ）を使うよう指示されている。
 |
非圧縮AVI形式で取り込んだ各フレームを分析するため，形式は細かく規定されているのだが，枝葉末節なので詳細は省く。基本的には「60fpsでドロップなしに非圧縮AVI形式で取り込む」よう指定されていると考えてもらえばいい。
取り込んだデータは，FCAT用にNVIDIAが介したツール「Extractor」（エクストラクタ）で読み出す。これは，フレームごとにカラーバーを分析し，統計データとして出力するものだ。
 |
 |
ちなみにここで用いるグラフ化アプリケーションは「gnuplot」（グニュプロット）で，これもオープンソースである。
以上がFCATの概要だが，ではFCATでどのようなデータが得られるのだろうか。続くテストパートでは，データの意味を説明しつつ，いくつか，実際のゲームアプリケーションを用いてテストしてみよう。
4GamerがFrapsでテストしているゲーム4タイトルをFCATにかけてみる
NVIDIAはFrapsで計測するフレームレートが必ずしも正しいとは限らないと指摘しているわけだが，4GamerでGPUの検証に用いているベンチマークレギュレーションだと，5月下旬時点の最新版となるバージョン14.0で，下記4タイトルでFrapsを用いた計測に頼っている。
- Far Cry 3
- Crysis 3
- The Elder Scrolls V: Skyrim
- SimCity
これら以外のタイトルは，Frapsを使わず，独自のベンチマークスコアを出してくるタイトルになる。詳しくは後で触れるが，独自のベンチマークスコアを出してくるタイトルでも，前節で指摘したのと同じ問題を抱えていたりするわけだが，NVIDIAはFrapsの信頼性が必ずしも100％とは言えないと主張しているので，今回はFrapsを使う上記の4タイトルに絞ってFCATによる検証を行うことにした次第である。
今回用意したグラフィックスカードは2枚。1つは「GeForce GTX 680」のリファレンスカード（以下，GTX 680）で，もう1つは，Sapphire Technology製の「Radeon HD 7970 GHz Edition」を搭載したリファレンスクロック採用モデル「VAPOR-X HD7970 GHZ EDITION 3G GDDR5 PCI-E」（以下，HD 7970 GE）だ。
テストに用いたグラフィックスドライバは，いずれもテスト開始時点の最新版で，具体的にはGTX 680用が「GeForce 320.18 Driver」で，HD 7970 GeForce GTX 650 Ti BOOSTが「Catalyst 13.5 Beta2」だ。Radeon用にはテスト開始後に「Catalyst 13.6 beta」も登場しているが，今回テストするゲームに向けた最適化やバグフィックスはアップデート内容に含まれていないため，最新ドライバを用いていないことの影響は無視できるレベルだと考えている。
 |
なお，CPUの「Core i7-3770K/3.5GHz」は，秋葉原のPC＆PCパーツショップであるパソコンショップ アークの協力を得て入手したものである。4GamerのGPUレビュー時と同じく，CPUの自動クロックアップ機能「Intel Turbo Boost Technology」は，テスト状況による効果の違いが生じる可能性を排除すべく無効化した。
 |
ベンチマーク用のPCからDVIスプリッタ経由でビデオ信号をVisionDVI-DLへ入力するにあたっては，表2に示した構成のPCを用いた。
 |
 |
FCATとFrapsを比較。違いが出ないものと出るものがある
では，タイトル順に見ていくことにしたい。テストはCrysis 3から始めたので，Crysis 3を最初に取り上げ，かつ，スコアの見方などもここで重点的に説明していくことをあらかじめお断りしておきたい。
■Crysis 3
というわけでCrysis 3だ。ベンチマークレギュレーション14.0では，Frapsで計測時間を60秒に指定したうえで，実際にゲームプレイを行うことが規定されているが，FCATでは「スタートからn秒間を自動的に計測」といったオプションは用意されていない。そのため，ビデオのキャプチャ開始と停止は手動で行わなければならず，「60秒きっかり」というわけにはいかない。とくにCrysis 3の場合は，テストにあたって実際にゲームをプレイしなければならないので，Frapsと比べると測定時間が5〜10秒程度は長くなると考えてほしい。
また前述のとおり，グラフはNVIDIAのスクリプトとgnuplotによって生成される都合上，4Gamerのハードウェア検証記事で見慣れた形式にはならない。この点もあらかじめご了承のほどを。
さて，4Gamer読者が最も気になるのは，「NVIDIAの言う『ドロップしたフレーム』や『不完全なフレーム』がどの程度あるのか」だろう。それを示すものが次に示すグラフだ。
グラフは横軸が経過時間（秒），縦軸がフレームレート。つまり，フレームレートの時間変化を表すグラフということになる。上がGTX 680，下がHD 7970 GEで，いずれも1920×1080ドット解像度のスコアとなる。
グラフの凡例にもあるとおり，Frapsによる計測データは黒い線で示される。ただし，「本物の」Frapsを使って測定したフレームレートではない。グラフ上に黒い線で示されるのは，「Overlayによってオーバーレイされたカラーバーのカラーを使ってカウントした，“Frapsと同等の”フレームレート」という意味である。
OverlayはFrapsと同様にDirectX APIを横取りしてカラーバーをオーバーレイさせているので，カラーバーの色を調べればFrapsが出すフレームレートと同じ値が分かる，というわけだ。
さらに，ドロップしたり不完全だったりしたフレームを差し引いたFrapsのフレームレートから差し引いたフレームレート――NVIDIAはこれを「Native FPS」（NFPS）と呼んでいるが，凡例には「FPS」としか書かれていない――は青い線で描かれる。
……のだが，ここでは黒い線の上に青い線が完全に重なっているため，黒い線は見えない。要するに，Native FPSとFrapsの測定データは一致しており，ドロップしたり不完全だったりするフレームはなかったという意味になる。今回のテスト条件だと，Frapsで取得したスコアに疑う余地はない，とも換言できるわけだ。
 |
| Crysis 3 - フレームレート推移：GTX 680（1920×1080ドット，高負荷設定） |
 |
| Crysis 3 - フレームレート推移：HD 7970 GE（1920×1080ドット，高負荷設定） ※グラフのタイトルには「Radeon_HD_7970」とありますが，前述のとおり，今回は「GHz Edition」を用いています。以下同 |
では，解像度2560×1440ドットではどうだろうか。その結果をまとめたのが次のグラフで，ここでもNative FPSと“Frapsの測定データ”は一致している。「1920×1080ドットと2560×1440ドットの高負荷設定，かつシングルカード構成において」という条件付きにはなるが，Frapsのデータはほぼ信頼していいと見ていいのではなかろうか。
 |
| Crysis 3 - フレームレート推移：GTX 680（2560×1440ドット，高負荷設定） |
 |
| Crysis 3 - フレームレート推移：HD 7970 GE（2560×1440ドット，高負荷設定） |
ちなみにFCATでは，さらに2つ，面白いグラフが得られる。1つは「パーセンタイル」，もう1つは「フレームタイム」だ。
パーセンタイル（percentile，分位点）というのは聞き慣れない言葉だと思うが，簡単に説明すると，データ（※FCATにおいてはフレームレート）がどのようにバラ付いているかを読み取れるものとなっている。
次に示すグラフがパーセンタイルのデータをまとめたものだ。先に述べたとおり，きっちり1分（3600フレーム）とはいかないが，おおむね3600フレームとして，3600個あるフレームレートが全体の中でどれくらいの割合を占めるのかがこのグラフから読み取れるようになっている。
グラフ縦軸は最小フレームレート，横軸はパーセンテージなので，この例なら，グラフ縦軸で20のラインをたどると，GTX 680においては約80パーセンタイルのところにある。よって「GTX 680におけるフレームレートの80％は20fps以上」と言える，といった具合である。
 |
最小フレームレートを大きく取るほど該当データの数が減るので，何か変なことがない限り，グラフは右肩下がりになる。一方，グラフの右端では最小フレームレート付近のバラツキが見える。つまり，グラフの形からGPUの特性というか，フレームレートのバラツキ方の違いが見えてくるわけだ。もっとも，ここでは比較対象の2製品に大きな違いはないのだが。
なお，上で示したのは解像度2560×1440ドット時のものだが，1920×1080ドットでも大きな違いはなかったことを付記しておきたい。
もう1つのフレームタイムをまとめたものが下のグラフだ。ここでは横軸が経過時間，縦軸が当該フレームを描画するのに要した時間」を示す。つまりは，フレームの描画時間がどのように変化するかを追ったものということになる。
ここではGTX 680もHD 7970 GEも基本的に一定の範囲で帯状のグラフになっているが，これはフレームの描画時間に相応の変動が生じているという意味になる。一部でところどころ跳ね上がっているのは，何らかの理由により，当該フレームを描くのに，例外的に長く時間がかかったものというわけだ。
 |
■Far Cry 3
FCATが生成するグラフの意味をざっくりと把握したところで，ここからは主にフレームレートの推移を見るグラフを取り上げ，面白い特徴があるデータではパーセンタイルのグラフも示すという形で進めていくことにしたい。
というわけでFar Cry 3である。本タイトルでも，レギュレーション14.0では1分間のフレームレートを計測することになる。Crysis 3と異なり，テストにあたってユーザー操作は不要なので，Frapsとの測定時間誤差はCrysis 3のときほど大きくはならないが，それでも数秒程度の誤差が出ている点はあらかじめお断りしておきたい。
フレームレートの推移は下にまとめたとおりで，1920×1080ドットと2560×1440ドット，どちらの条件でも，FCATとFrapsの測定データは一致した。掲載は見送るが，パーセンタイルといフレームタイムもGTX 680とHD 7970 GEの間で大きな違いはなし。つまり，Crysis 3と同様，FCATならではというデータは取れなかった（＝Frapsのテスト結果に信頼が置ける）タイトルということになる。
 Far Cry 3 - フレームレート推移：GTX 680（1920×1080ドット，高負荷設定） |
 Far Cry 3 - フレームレート推移：HD 7970 GE（1920×1080ドット，高負荷設定） |
 Far Cry 3 - フレームレート推移：GTX 680（2560×1440ドット，高負荷設定） |
 Far Cry 3 - フレームレート推移：HD 7970 GE（2560×1440ドット，高負荷設定） |
■The Elder Scrolls V: Skyrim
いきなりテスト開始から2タイトル連続でFCATとFrapsで大きな違いがなかったわけだが，The Elder Scrolls V: Skyrim（以下，Skyrim）ではついに違いが生じた。
すでに述べたように，FCATは動画をキャプチャし，Extractorで統計データを出し，スクリプトで処理するという手順をとる。そして，Skyrimでも正常な動画はキャプチャでき，VirtualDubを使った検査ではビデオにドロップがないことも確認できているのだが，最後にスクリプトで処理しようとすると，「ドロップしたフレームがある」というエラーが発生してしまうことがあるのだ。
くどいほど何度もやり直したのだが，GTX 680では最後まで2560×1440ドット解像度のデータを取ることができなかった。そのため今回は当該データを割愛する。データを取得できなかった原因は不明だが，何か分かったらあらためてお伝えしたいと思う。
なお，Skyrimのテストもベンチマークレギュレーション14.0準拠。先の2タイトル同様，測定時間には手動操作によるばらつきがある。
 |
 |
さて，そういうわけで，今回はGTX 680とHD 7970 GEを問題なく比較できる1920×1080ドットでSkyrimのスコアを見ていこう。
まずはGTX 680からだが，46秒と50秒のところで，青い線と黒い線の乖離を確認できる。このグラフだけだと読み取れないが，統計データを調べると，GTX 680では合計3フレームのRunt Frameが生じたことが分かった。本稿の序盤でも触れたように，Runt Frameは20ライン以下しか描画されなかった不完全なフレームのことだ。なお，ドロップしたフレームはゼロである。
 |
一方のHD 7970 GEでは，テスト開始直後の3〜5秒後に，青い線と黒い線の大きな乖離を確認できた。また，15秒，35秒，46秒にも小さな乖離が見られる。
なお統計データによると，テスト合計で不完全なフレームが12あり，ドロップはゼロだった。
 |
 |
というのは，FCATで得られるCSV形式の統計データで，FrapsのフレームレートとNative FPSを知ることができるためだ。ここで示した画面はまさにSkyrimのものだが，不完全なフレーム数はごく少なく，フレームレートに大きな影響を与えるものではなかった。
Skyrimでは，GTX 680とHD 7970 GEのパーセンタイルにも有意な差が現れた。それが下のグラフだが，グラフの形状に大きな違いがあることは一目で分かるだろう。GTX 680ではほどよいバラツキになっていて，フレームレートの変動幅が大きくないのに対し，HD 7970 GEでは，少ないサンプル数ながら極端に高いフレームレートが記録されている。
極端に高いフレームレートが記録される一方で，グラフ右肩はGTX 680より低いというのは，低いフレームレートも多く混ざっているということを意味している。つまりHD 7970 GEのほうがフレームレートの変動幅が大きく，描画が安定していないことを窺わせる結果になっているのである。
 |
前述のとおり，2560×1440ドット解像度では，HD 7970 GEでしかスコアが取れなかったが，フレームレートは露骨に分かりやすいデータとなった
青い線と黒い線の間を，橙と赤がまんべんなく埋めており，不完全なフレームの発生とフレームのドロップが全体にわたって生じていたことが分かる。統計データによると，不完全なフレームは232，ドロップしたフレームは137あった。
Frapsの計測値は84.62fpsになるが，不完全なフレームやドロップしたフレームを差し引いたNative FPSは77.24fpsと，かなり大きな開きがあることも統計データで示されている。
 |
残念ながら，GTX 680との比較ができないため，不完全なフレームやドロップしたフレームが多かった理由は推測できないが，GTX 680やHD 7970 GEといったハイエンドクラスのGPUにとって，Skyrimの描画負荷が低いのが原因かもしれない。HD 7970 GEで，フレームレートのばらつきが非常に大きくなっていることから，60Hzで映像を送り出すときに表示されるフレームが安定しないというというのは大いに考えられるだろう。
SimCity
SimCityは，ベンチマークレギュレーション14だと120秒間の計測が規定されているのだが，FCATで120秒間の計測を行うと非圧縮のキャプチャデータが極めて大きくなり，ときとして空き容量が厳しくなることから，今回はテスト開始から（約）60秒間のデータで留めることにした。
計測時間以外はレギュレーション準拠である。
解像度1920×1080ドット時のスコアは次に並べて示したとおり。HD 7970 GEで開始8秒後に若干の乖離が見られるほかは安定している。
 SimCity - フレームレート推移：GTX 680（1920×1080ドット，AA＆AF有効化設定） |
 SimCity - フレームレート推移：HD 7970 GE（1920×1080ドット，AA＆AF有効化設定） |
一方の2560×1440ドットでは，テスト対象となる2製品のどちらでもまんべんなく不完全なフレームが生じ，HD 7970 GEでは一部でフレームのドロップも生じたことが分かる。GPUに関わらず同じような傾向が出ているので，まんべんなく生じている不完全なフレームは，ゲームタイトルの特性とみるべきだろう。実際，パーセンタイルやフレームタイムに特徴的な違いはなかった。
 |
| SimCity - フレームレート推移：GTX 680（2560×1440ドット，AA＆AF有効化設定） |
 |
| SimCity - フレームレート推移：HD 7970 GE（2560×1440ドット，AA＆AF有効化設定） |
ちなみに，統計データによれば，2560×1440ドット解像度における不完全なフレームの数はGTX 680が225，HD 7970 GEが248。ドロップはGTX 680が0，HD 7970 GEが17だった。
そのため，Frapsの計測値とNative FPSとの間にはもちろん開きが生じており，GTX 680ではFrapsが63.94fpsに対してNative FPSは59.53fps，HD 7970 GEではFrapsが72.06fps，Native FPSが66.96fpsで，約7％の開きがあった。
つまり，SimCityの2560×1440ドットだと，ユーザー体験的にはFrapsから7％ほど低いフレームレートになるということだろう。
マルチGPU構成にすると，GeForceとRadeonの間には大きな違いが
続いてはマルチGPU構成のテストだ。ここからは，表1のシステムに，もう1枚のGTX 680のリファレンスカード，もしくは追加のHD 7970 GEリファレンスカードを足して，SLIあるいはCrossFire構成を構築したうえでテストを行っていく。グラフィックスカードの構成以外は何も変更していない。
ただし，テストに用いるタイトルはCrysis 3とFar Cry 3に絞る。Skyrimではシングルカード構成時にもあった「測定データが安定しない」問題がSLI動作時に悪化したこと，SimCityはそもそもマルチGPU構成でフレームレートの向上を期待できないことがその理由である。
では，またCrysis 3から見ていこう。
■Crysis 3
Crysis 3のマルチGPU構成では1920×1080ドットにおいて非常に興味深いデータが得られた。
下に示した2本のグラフを見ると，異常が生じているのはHD 7970のCrossFireだというのはすぐに分かるだろう。不完全，もしくはドロップしたフレームの数が異常に多いのだ。
ただ，測定をミスしている可能性は極めて低い。というのも，NVIDIAでも内部で4Gamerの測定結果に近いデータを持っていることが示唆されたためである。FCATを公開した理由を「ゲーマーと知識を共有したいから」と述べているNVIDIAだが，もしかすると，マルチGPU構成時の結果を見せて，「ゲーマーと（SLIとCrossFireではこんなに違うという）知識を共有したい」のではないかという気もしてくる。
 |
| Crysis 3 - フレームレート推移：GTX 680 SLI（1920×1080ドット，高負荷設定） |
 |
| Crysis 3 - フレームレート推移：HD 7970 GE CrossFire（1920×1080ドット，高負荷設定） |
いずれにしても，HD 7970 GEのCrossFire構成だと，Frapsで得られる平均フレームレートとNative FPSの違いも極めて大きい。GTX 680 SLIの場合，Frapsのスコアが57.15fps，Native FPSが57.05で，違いは0.2％もないのだが，HD 7970 GEのCrossFireだとFrapsのスコアが93.32fpsのところ，Native FPSはなんと45.05fps。約48.3％しか出ていないのである。
なぜこのような結果になるのか推測するのは難しいが，これほど極端な“症状”だと，先に述べたようなGPUやドライバのエラーも疑える。実際，パーセンタイルを見てみると，HD 7970 GEのCrossFireでは極端に高いフレームレートが計測されるなど，バラツキが非常に大きい。これは何らかの問題が生じている結果かもしれない。
 |
さらに疑り深い見方をするなら，AMDのグラフィックスドライバが部分的にシーンの描画を端折っているということもあり得なくはない。というのは，解像度を高くしてグラフィックス描画負荷を引き上げると，下にグラフで結果を示したとおり，HD 7970 GE CrossFireの持つ症状はぴたりと治まってしまうためだ。
もちろん，だからといって「AMDが特定の解像度に対して強引な最適化を行っている」と断言できるものではないのだが，「解像度を変えるといきなり問題がなくなる」というのが不自然なのも，また確かである。
 |
| Crysis 3 - フレームレート推移：GTX 680 SLI（2560×1440ドット，高負荷設定） |
 |
| Crysis 3 - フレームレート推移：HD 7970 GE CrossFire（2560×1440ドット，高負荷設定） |
■Far Cry 3
Far Cry 3も1920×1080ドットからだ。
GTX 680のSLIでは合計4フレームの不完全なフレームが見られた。一方，HD 7970 GEのCrossFireではドロップしたフレームがやや多く，合計45に及んだ。また，不完全なフレームは19だった。そのため，Native FPSはHD 7970 GE CrossFireのほうがやや低めに出る。
 |
| Far Cry 3 - フレームレート推移：GTX 680 SLI（1920×1080ドット，高負荷設定） |
 |
| Far Cry 3 - フレームレート推移：HD 7970 GE CrossFire（1920×1080ドット，高負荷設定） |
 |
その結果，Frapsの測定結果と比べると，GTX 680 SLIのNative FPSは約6％，HD 7970 GE CrossFireのNative FPSだと約14.5％低く出ている。Crysis 3のような不信な挙動はないため，ユーザー体験的なフレームレートを探るときは，この低下率がひとつの目安になりそうだ。
 |
| Far Cry 3 - フレームレート推移：GTX 680 SLI（2560×1440ドット，高負荷設定） |
 |
| Far Cry 3 - フレームレート推移：HD 7970 GE CrossFire（2560×1440ドット，高負荷設定） |
ゲームタイトルによって異なる傾向を見せるFCAT計測結果。「フレームレート計測」について考えさせられる
以上，FCATを試してきたが，興味深いデータが得られた，というのが率直な感想だ。Crysis 3を前にしたときの，マルチGPU構成における結果を見せつけられたりすると，NVIDIAがFrapsの測定結果に疑問を呈するのも無理はない印象を受ける。
4Gamerの読者の中にも，Frapsで高いフレームレートが記録できているのに，体感だとあまりフレームレートが高いとは思えないという経験をしている人がいるかもしれない。4Gamerのベンチマークレギュレーションでは，そういう状況を踏まえ，合格点となるフレームレートを高めに設定したりすることで対策しているわけだが，そういった「Frapsと体感とのギャップ」が，不完全なフレームやドロップしたフレームによるものだと考えることは十分に可能だろう。
たとえば，SimCityにおける高負荷環境のように，GPUの違いに関係なく，“安定して”不完全なフレームやドロップしたフレームが見られるタイトルなら，FCATのデータは参考になると思われる。Frapsの測定値から7％さし引いた程度が体感的なフレームレートになると考えられるからだ。
だが，特定のGPUのマルチGPU構成といったピンポイントの条件で不完全なフレームやドロップしているフレームが多発するケースも生じ得るということが，今回のテスト結果からは分かる。そして，そういった特定条件で発生する不完全フレームやドロップしたフレームは，FCATを用いて丹念に調べるしか知る方法がない。
「なら，4Gamerの普段のテストでもFCATを使えばいいのではないか」という議論は出てくると思うが，結論からいうと，そう簡単な話にはならない。機材の問題はさておくとしても，その手間を考えると，スピードが要求されるWebメディアの常用に堪えるものではないと結論付けざるを得ないからである。
ただ，FCATで非常に興味深い結果が得られ，またユーザーとしても参考になる結果が出ているのは確かだろう。今後，ベンチマークレギュレーションのアップデート時にFCATを利用することで，よりレギュレーションの精度は上げられるかもしれない。これは4Gamerとしての検討課題となりそうだ。
また，今回はテストを割愛したが，3DMarkのようなソフトウェアでフレームレートを計測するベンチマークスイートでも，不完全なフレームやドロップしたフレームが多発している可能性は十分にある。ソフトウェア的に「ユーザーが目にするフレームの数」調べる方法は筆者が考えられる限りでは存在しないため，Frapsを使わずにスコアを求める3DMarkのようなテストでも面白い結果が得られる可能性はあるだろう。
冒頭でも紹介したとおり，NVIDIAはFCATをパッケージ化して販売したりする計画はないとしている。そのため，エンドユーザーが試す機会はないと思われるが，NVIDIAがベンチマークのグラフを出してきたら，本稿でここまで語ってきた内容のようなテストを行っているのだと思い出すと，スコアの見方が変わってくるかもしれない。
NVIDIA日本語公式Webサイト
- 関連タイトル：
ベンチマーク - この記事のURL：
4Gamer.net最新情報
プラットフォーム別新着記事
総合新着記事
企画記事
新着連載
新着レビュー
