「マルチGPU構成時のフレーム表示異常」解消は本当か。Catalyst 13.8 Betaにおける新機能「Frame Pacing」の挙動を調べてみた

　北米時間2013年8月1日，AMD製GPUおよびAPU向けグラフィックスドライバの公式最新β版となる「Catalyst 13.8 Beta」が公開になった。

　リリースを受けた紹介記事内でも指摘したとおり，今回のリリースは，NVIDIAの掲げた疑義に対する回答という色合いが濃い。簡単にいえば，NVIDIAが「RadeonのCrossFire環境では，フレーム表示に異常があるのではないか」と暗にツッコんでいたことに対し，6月上旬の「Catalyst 13.6 Beta2」リリース後，約2か月かけて対策してきた結果が，今回の13.8 Betaドライバというわけだ。

　NVIDIAが指摘する表示異常というのは，4Gamerでも先に掲載したテスト記事で確認できているが（関連記事），Catalyst 13.8 BetaにおけるAMDの対策というのは一体何なのか。調査してみたので，その結果をお伝えしてみたい。

AMDはCatalyst 13.8 Betaで何を修正したのか

　テストに先立って，AMDがこの2か月で行ったことを，いま分かっている範囲でまとめておこう。
　前提となる話をしておくと，そもそもの発端は，NVIDIAがGPUやドライバの開発にあたって実際に社内で使用しているというツール「Frame Capture Analysis Tool」（以下，FCAT）にある。

FCATのテストレポートより，FCATシステムの概要

　「FCATとは何か」という話は，FCATそのもののテストを行った記事に詳しいので，ぜひそちらを参照してもらえればと思うが，簡単におさらいしておくと，これは，グラフィクスカードからのディスプレイ出力を，高速なキャプチャシステムで動画として保存し，その動画を分析することで，ディスプレイには出力されていないフレーム（＝ドロップしたフレーム）や，ディスプレイに20ライン以下の高さでしか表示されないフレーム（＝不完全なフレーム）を検出するツール一式だ。
　そのFCATを用いると，AMD製GPUの場合，とくにCrossFire環境で，ドロップしたフレームや不完全なフレームレートが多発するケースがあった。そこでAMDは，NVIDIAからの指摘を真正面から受け止め，Catalyst 13.8 Betaで，表示異常を抑えるべく，改善を図ってきたのである。

Catalyst Control Centerの「3Dアプリケーション設定」以下に，「Frame Pacing」の項目が追加された。CrossFire環境でのみ表示され，規定は「オン」となる

　どのように抑えたのか，AMDはざっくりとしか述べていないのだが，Catalyst 13.8 Betaのリリースノートによれば，CrossFireを構成する各GPUがレンダリングするフレームを，規則正しく表示されるようにしたのだそうだ。AMDはこの機能を「Frame Pacing」（フレームペーシング）としてドライバユーティリティソフト「Catalyst Control Center」に追加し，標準で有効化してきている。
　裏を返せば，Catalyst 13.6 Beta2以前では，この「各GPUがレンダリングするフレームを規則正しく表示する」機能がなかったわけだ。

　もう少し細かく考察してみよう。
　AMDのCrossFireでは，複数のGPUにレンダリング処理を割り振るにあたって，下記のとおり，3通りの方法を用意している。ゲームタイトルごとに，「Catalyst A.I.」という機能によって，最適な処理が自動的に選択されるという触れ込みだ。

• Alternate Frame Rendering：1フレームずつ順番に複数のGPUへ振り分けてレンダリングを行う
• Super Tiling：1フレームをGPUの数に応じてタイルに分割し，それぞれのタイルを各GPUへ振り分けてレンダリングを行う
• Scissor：フレームをGPUの数で水平に分割し，各GPUに振り分けてレンダリングを行う（※NVIDIAのSLIで言うところの「Split Frame Rendering」と同じ）

　ただ，「3モードのうち，適切なモードが自動選択される」といっても，実際問題，CrossFireで大きくフレームレートを向上させられるのは，Alternate Frame Rendering（以下，AFR）だけだ。一般にCrossFireと聞いて期待される「複数のGPUによる大幅なフレームレート向上を実現する動作モード」は，事実上，AFRのことだという理解でいい（※Super TilingやScissorではフレームレートが上がらないということではない）。

　ただ，そのAFRにも弱点がある。以下は便宜的にGPUを2基として話を進めるが，あるフレームと次のフレームを2つのGPUに振り分けたとして，何らかの理由で片方のGPUが短時間でレンダリングを終え，もう一方のGPUはレンダリングに時間がかかったとする。このようなケースでまともに表示を行おうとすると，遅い側のGPUにフレームの表示のタイミングを合わせざるを得ない。

　もちろん，2つのGPUに振り分けられるフレームは時間的に隣り合っているので，描かれている映像は大差ないことが多いだろう。だが，隣り合ったフレームの映像に違いが大きかったり，ドライバやGPU側の処理に何か問題が生じていたりするケースでは，2基あるGPUでレンダリング時間が変わることはあり得る。

　AMDやNVIDIAはAFRモードに関する詳細な情報を公開していないため，ここから先は推測になるのだが，おそらく，ゲームタイトルによってマルチGPUの効果が大きく異なるのは，ゲームで描かれる映像の違いや，レンダリング手法の違いといった部分で，2つのGPUの協調が取りやすかったり，取りにくかったりといったことが起こっているためなのだろう。
　そして，従来のCatalystでは，CrossFireのAFRモードで上記のようなケースに遭遇したとき，フレームの表示タイミング調整を行わずにいたのではなかろうか。Catalyst 13.8 Betaで「フレームを規則正しく表示する」（原文：be displayed at an even and regular pace）としているのは，マルチGPUの表示のタイミングを正しく合わせるようにした，という意味だと思われる。

　先に掲載したFCATのテストレポートで，表示異常の出現パターンがゲームタイトルによって異なっていたのを記憶している人も少なくないと思われるが，これは，AFRを使って積極的に高速化が図られているタイトルのうち，2つのGPUのレンダリング時間にばらつきが生じやすいタイトルで表示の異常が顕在化すると考えれば納得できる。
　ただ，先に述べたようにマルチGPUの表示のタイミングを正しく合わせると，遅い側のGPUに表示が引っ張られることにもなるので，フレームレートは低下傾向になるかもしれない。Frame Pacingが機能するのかだけでなく，Frame Pacingを有効化することで，フレームレートが下がってしまったりしないのかという部分も，今回のテストではチェック項目となるだろう。

今回のテストではRadeon HD 7990を使用

　テストのセットアップに入っていきたい。FCATを用いた検証では，実際にベンチマークを実行するPCとは別に，録画を行うPCが必要になるが，後者は6月にFCATのテストを行ったときのPCを確保してあったので，これをそのまま流用する。スペックが気になる人は，FCATのテストレポート記事をチェックしてもらえればと思う。

HD 7990リファレンスカード。テストには本製品を用いた

　一方，実際にベンチマークテストを行うほうのPCは表のとおり刷新している。FCATのテストレポート記事からの最も大きな違いは，「Radeon HD 7970 GHz Edition」（以下，HD 7970 GE）搭載グラフィックスカードのCrossFire構成ではなく，カード上でCrossFire構成となっているデュアルGPUソリューション，「Radeon HD 7990」（以下，HD 7990）のリファレンスカードを用いていることだが，これに他意はない。Catalyst 13.8 BetaのFrame Pacingを検証しようと，日本AMDに関連情報を請求したところ，担当者から「テストはHD 7990で行ってもらえませんか」とリクエストがあったという話に過ぎず，それ以上でも以下でもないので，この点はあらかじめお断りしておきたいと思う。
　HD 7990の示すフレームレート傾向および実フレームレートはHD 7970 GEのCrossFire構成とほとんど同じなので（関連記事），大きな問題はないはずだ。


　なお，CPUの自動クロックアップ機能「Intel Turbo Boost Technology」は，テスト状況によって挙動が異なる可能性を排除すべく，無効化してある。

　テストに用いるアプリケーションは，4Gamerのベンチマークレギュレーション14.0で採用するタイトルから，「Far Cry 3」と「Crysis 3」，「The Elder Scrolls V: Skyrim」（以下，Skyrim）と「SimCity」の4タイトルだ。いずれも，6月のFCAT検証記事で用いたものである。
　また，テスト時の解像度も同記事に準じる。つまり，テスト環境や方法を揃えることで，先の記事の続編として参照できるようにしたというわけだ。

タイトルごとの違いはあるものの，総じて「表示異常」への対応は確認できる結果に

　では，タイトルごとに見ていこう。

■Far Cry 3

　Far Cry 3のテストにあたってはベンチマークレギュレーション14.0に準拠し，グラフィックス設定は「高負荷設定」としているが，FCATでは録画マシン側での操作が必要になる関係から，録画の開始と終了は手作業となるため，レギュレーションで規定する1分きっかりの計測にはならない。この点を注意してもらいつつ，まずは，解像度1920×1080ドット時においてFCATが出力した，約1分間のフレームレート推移を見てみよう。

　下に示した3枚のグラフ画像は順に，Catalyst 13.6 Beta2導入時，Catalyst 13.8 Betaを導入してFrame Pacingを無効化した状態，逆に有効化した状態となる。グラフは横軸が時間，縦軸がフレームレートで，赤く表示されている部分が「レンダリングは行われたが，画面には表示されない」フレーム，つまりドロップしたフレームだ。オレンジ色で表示されている部分が画面に20ライン以下でしか表されていない不完全なフレームとなる。

　というわけで3枚のグラフを比較してみると，Catalyst 13.6 Beta 2とFrame Pacingを有効化したCatalyst 13.8 Betaは，赤い領域の数が9つで揃った。一方，Frame Pacingを無効化したCatalyst 13.8 Betaだと，赤い領域の数は3つで，代わりにオレンジ色の領域が増えていることが分かるだろう。

Far Cry 3：Catalyst 13.6 Beta2（1920×1080ドット，高負荷設定）

Far Cry 3：Catalyst 13.8 Beta - Frame Pacing無効（1920×1080ドット，高負荷設定）

Far Cry 3：Catalyst 13.8 Beta - Frame Pacing有効（1920×1080ドット，高負荷設定）

　実際，FCATがCSV形式で出力した統計データでも，ドロップしたフレームの数はCatalyst 13.6 Beta2とFrame Pacingを有効化したCatalyst 13.8 Betaともに150で変わらず。対して，Frame Pacingを無効化したCatalyst 13.8 Betaは45となっていた。
　不完全なフレームはCatalyst 13.6 Beta2が20で，Catalyst 13.8 BetaはFrame Pacing無効時が13，有効時が10。Catalyst 13.8 Betaでは，Frame Pacingの無効/有効にかかわらず，不完全なフレームの数が若干減っているわけだ。

　要するに，Far Cry 3においては，Frame Pacingを無効化したほうが，標準状態となる有効化時よりも，フレーム表示異常は抑えられているというわけだ。少なくとも，ここでFrame Pacingの効果は見られないと述べていいだろう。

　続いて，解像度を2560×1440ドットまで引き上げたときのテスト結果も下にまとめたが，ここではCatalyst 13.6 Beta2とCatalyst 13.8 Betaの間には大きな違いがある。しかし，Frame Pacing無効化時と有効化時の間に大きな違いはないようだ。

Far Cry 3：Catalyst 13.6 Beta2（2560×1440ドット，高負荷設定）

Far Cry 3：Catalyst 13.8 Beta - Frame Pacing無効（2560×1440ドット，高負荷設定）

Far Cry 3：Catalyst 13.8 Beta - Frame Pacing有効（2560×1440ドット，高負荷設定）

　ここでも統計データを頼りにしてみると，ドロップしたフレームは順に297，91，60で。不完全なフレームは順に233，160，188。この解像度でも，はCatalyst 13.6 Beta2からCatalyst 13.8 Betaへのアップデートによるフレーム表示異常の改善は見られるが，Frame Pacing機能に明らかな効果が出ているとは認めがたい。
　1920×1080ドット時のテスト結果も踏まえるに，Catalyst 13.8 BetaでFar Cry 3でフレーム表示異常は確実に改善されたが，それはFrame Pacing機能以外の要因によるものと推測できそうだ。

■Crysis 3

　Crysis 3もFar Cry 3と同じく，レギュレーション14.0のテスト方法に準拠し，高負荷設定でテストを行う。Crysis 3のテストでは実際にゲームをプレイする必要があるため，録画開始および終了タイミングの誤差がかなり大きい点に注意してほしい。また，60秒間のゲームプレイ後は，操作を中断し，録画機側の操作を行うため，フレームレートが跳ね上がる場合があるのだが，この部分は無視してもらえればと思う。

　というわけで，ここでも解像度1920×1080ドット時の結果から見ていくが，6月の検証時と同じく，この解像度だと，Catalyst 13.6 Beta2を用いる限り，ドロップしたフレームや不完全なフレームは見られない。しかし，Catalyst 13.8 Betaだと，Frame Pacingの無効化，有効化を問わず，ドロップしたフレームも不完全なフレームも見られるようになった。

　その一方で，Native FPSを見てみると，Catalyst 13.6 Beta2で平均30.fpsだったところが，Catalyst 13.8 BetaではFrame Pacing無効時に平均59.9fps，有効時に平均54.7fpsへと，大きく上がっているのは目を引く（※上で指摘したとおり，Frame Pacing無効時には「操作終了後のフレームレート跳ね上がり」が確認されているので，Frame Pacing無効時と有効時に有意な違いはないと見ておいたほうが安全だ）。

　ドロップしたフレームの数はFrame Pacing無効時に75，有効時に60。不完全なフレームの数は順に34，4となる。となると，ついに「Frame Pacingの有効化効果が出た」ということになりそうだが，Catalyst 13.6 Beta2の結果と比べるとFrame Pacingの無効/有効にかかわらずドロップしたフレームがむしろ増えている点は見逃せないところである。Catalyst 13.6 Beta2比でフレーム表示異常が増えている以上，Frame Pacingの効果がはっきりと認められるとは言いがたい。

Crysis 3：Catalyst 13.6 Beta2（1920×1080ドット，高負荷設定）

Crysis 3：Catalyst 13.8 Beta - Frame Pacing無効（1920×1080ドット，高負荷設定）

Crysis 3：Catalyst 13.8 Beta - Frame Pacing有効（1920×1080ドット，高負荷設定）

　下に3枚並べたグラフ画像が解像度2560×1440ドットにおける結果だ。Catalyst 13.6 Beta2だと，ドロップしたフレームが34，不完全なフレームが78計測され，Frame Pacingを無効化したCatalyst 13.8 Betaでも順に36，87と，ほとんど変わらない。それに対してFrame Pacingを有効化すると，ドロップしたフレームはわずか4まで減り，不完全なフレームは0という結果になった。
　つまり，2560×1440ドットでは，Frame Pacingの有効化によって見事にドロップしたフレームを抑え込めているわけである。

　ただ注意したいのは，Frame Pacingを有効化したときの平均Native FPSが約22.1fpsと，Catalyst 13.6 Beta2の約43.4fps，Frame Pacingを無効化したCatalyst 13.8 Betaの41.3fpsと比べて，半分強にまで落ち込んでいる点だ。1920×1080ドットでのテスト結果とは，まったく異なる傾向が出たことになる。

Crysis 3：Catalyst 13.6 Beta2（2560×1440ドット，高負荷設定）

Crysis 3：Catalyst 13.8 Beta - Frame Pacing無効（2560×1440ドット，高負荷設定）

Crysis 3：Catalyst 13.8 Beta - Frame Pacing有効（2560×1440ドット，高負荷設定）

　Crysis 3のテスト結果で面白いのは，Catalyst 13.6 Beta2導入時には解像度1920×1080ドット時にフレーム表示異常が抑えられ，Native FPSが落ち込んでいる一方，2560×1440ドット時にはFrame Pacingを有効化したCatalyst 13.8でフレーム表示異常が抑えられ，いずれの場合にもNative FPSの落ち込みを伴ったことだろう。

　フレーム表示異常が抑えこまれ，Native FPSは向上するか維持するかというのが理想的だが，少なくとも今回のテストではそうなっていない。本稿の序盤で推測したように，2基あるGPUのフレームの表示タイミングを合わせることの副作用は意外に大きいのかもしれない。

■Skyrim

　Skyrimでも設定はレギュレーション14.0の「Ultra設定」準拠だが，解像度は1920×1080ドットのみとなる。理由はFCATのテストレポートでもお伝えしたとおり，解像度を2560×1440ドットに設定すると，安定して録画できないためだ。

　その結果が下に示したグラフ画像だが，まず気づくのは，Catalyst 13.8 Betaを導入してFrame Pacingを無効化したときの結果だけ，大きく異なっていることだろう。
　これは，レギュレーション14.0の紹介文でも指摘している「シークエンス序盤がやや不安定」という症状が，最初の10秒程度で発生したため，グラフでも序盤の10秒程度はフレームレートが大きく乱れている。ただし，その後はシークエンスの進行が安定しているので，最初の10秒程度を除けば“使える”データだと考えてほしい。

　さて，Catalyst 13.6 Beta2とCatalyst 13.8 Betaで比較してみると，ドロップしたフレームの数が減っているのが分かる。統計データを見てみても，Catalyst 13.6 Beta2では240だが，Frame Pacingを無効化したCatalyst 13.8 Betaでは30，有効化しても60と，その違いは明らかだ。
　さらに平均Native FPSは，Catalyst 13.6 Beta2の約87.6fpsから，Frame Pacingを有効化したCatalyst 13.8 Betaで約93.4fpsと，約7％の向上が見られる。

Skyrim：Catalyst 13.6 Beta2（1920×1080ドット，Ultra設定）

Skyrim：Catalyst 13.8 Beta - Frame Pacing無効（1920×1080ドット，高負荷設定）

Skyrim：Catalyst 13.8 Beta - Frame Pacing有効（1920×1080ドット，高負荷設定）

　以上の結果から，Skyrimにおいては，Catalyst 13.6 Beta2からCatalyst 13.8 Betaへのアップデートにより，フレーム表示異常はかなり抑え込まれ，性能面での最適化も進んだと見ていいだろう。
　だが，Frame Pacingの無効/有効でフレーム表示異常の傾向に大差が見られないことからすると，Skyrimにおける改善は，Frame Pacing機能の実装とは無関係と見るほうが正しいと思われる。

■SimCity

　レギュレーション14.0を導入したときのテストレポートで，マルチGPU動作の恩恵が受けられないタイトルだと紹介しているSimCityでも，念のためテストしておこう。今回はレギュレーション14.0の「AA＆AF有効化設定」を有効化のうえ，テスト解像度は1920×1080のみに留めている。
　また，これはCrossFireとは関係ないが，録画されるビデオファイルのサイズが大きくなりすぎることから，テスト時間はレギュレーションで規定する2分ではなく，1分とした。

　その結果が下に3枚並べたグラフ画像だ。ドロップしたフレーム数は，Catalyst 13.6 Beta2とFrame Pacingを有効化したCatalyst 13.8 Betaが揃って150，Frame Pacing無効時が180となった。Frame Pacing無効時はドロップしているフレームがやや多く，実際にグラフでもそう見える結果になっている。

　ただし，Crysis 3のような「フレーム表示異常が減る代わりに平均Native FPSが下がる」という傾向は，ここでは確認されない。また，Frame Pacingを有効化しても，ドロップしているフレーム数の減少効果は（少なくともCatalyst 13.6 Beta2比では）認められないことから，Frame Pacingによるプラスの影響が出ていると言い切るのは難しそうだ。

SimCity：Catalyst 13.6 Beta2（1920×1080ドット，高負荷設定）

SimCity：Catalyst 13.8 Beta - Frame Pacing無効（1920×1080ドット，高負荷設定）

SimCity：Catalyst 13.8 Beta - Frame Pacing有効（1920×1080ドット，高負荷設定）

　Frame Pacing無効化時にドロップするフレームが増えたのは，単に測定の揺らぎの影響か，実際に行ったゲームプレイの影響といったことも考えられるだろう。

Frame Pacingはタイトルごとの個別対応か

AMDはさらなる改良を予告

　以上，テスト結果を見てきたが，Crysis 3の2560×1440ドット時にFrame Pacingの効果がはっきりと見られたものの，それ以外のテスト条件では，効果があるようなないような，全体としてはなさそうなという，もやもやした結果になってしまった（表2）。
　Frame Pacingの効果を，「フレーム表示異常を明らかに抑え込めていること」だと定義するなら，それを満たしているのは，今回のテスト結果だと，Crysis 3の解像度2560×1440ドット時のみだ。サンプル数が少ないので，Crysis 3以外にもFrame Pacingが効くタイトルはあるかもしれないが，現時点ではCrysis 3の超高解像度でしか効果はないという可能性は捨てきれない。

※表内の記号は，◎が改善，○がやや改善，◇がほぼ変わらず，▽がやや悪化，▼が悪化を示す

　というのも，6月1日掲載のテストレポートで明らかになっているとおり，フレーム表示異常の出方は，ゲームタイトルや解像度設定によって，かなり異なっていたからだ。したがって，AMDが表示の異常が大きく表れるタイトル＆解像度に絞り込んで対策を行っていたとしても不思議はない。要するに，今回のβリリースではCrysis 3の高解像度環境に絞って対策してきたのではないか，ということである。

　AMDが主張するように，Frame Pacingと呼ばれる方法で2基あるGPUの表示タイミングを合わせてフレーム表示異常を解決できるなら，たとえばFar Cry 3でもFrame Pacing有効時に何からの違いが出てもいいだろう。「Far Cry 3ではFrame Pacingが十全に機能しないことを確認済みで，それは次回のドライバアップデートで対応予定」とされていることも（関連記事），Frame PacingでAMDがゲームタイトルや解像度ごとに個別対応を行っていることの示唆ではないかと，筆者は見ている。

　この推測が正しいのであれば，NVIDIAが指摘した，CrossFire構成時におけるフレーム表示異常の原因は，一律ではないということになるだろう。何か致命的なバグがあって，それを解決すればさくっと直る，というようなものではなく，もっと複雑で，だからこそAMDは，Catalyst 13.6 Beta2のリリースからCatalyst 13.8 Betaのリリースまでに，約2か月も時間をかけたのかもしれない。

　実際，AMDとしても「CatalystにFrame Pacingを実装して終わり」にするつもりはないようなので，この点は今後に乞うご期待，といったところだろう。ただ，Catalyst 13.8 Betaについてまとめるなら，現時点におけるFrame Pacingの効果は「間違いなくあるが，極めて限定的」ということになると思われる。

AMDのCatalyst 13.8 Beta配布ページ（英語）

AMDの製品サポートページ（英語）