GPUやドライバ，ディスプレイは「ゲームプレイの速度」についていけているのか？ 操作遅延計測用デバイスを開発してみた

　突然だが，ディスプレイ機器を見るに当たって，「操作遅延」の存在を考えたことがあるだろうか。「PCやゲーム機から出力された映像がディスプレイ機器で表示されるまでの時間」を示す「表示遅延」ではない。「マウスやキーボードを操作してから，その操作が実際に画面に反映されるまでの時間」のことである。

　操作遅延はグラフィックスドライバの良し悪しだけでなく，ディスプレイやPCの性能，グラフィックスカードの性能，果てはゲームプログラムの設計や質にも左右される。なので，ゲーム用のデバイスを選択するときに，操作遅延は極めて重要な指標となる数字と言っていいだろう。操作遅延が測定できればゲーマーに役に立つデータを提示できるはずだ。
　4Gamerでは，グラフィックスカードの消費電力計測ツール「4Gamer GPU Power Checker Version 1.1」の完成後から，操作遅延計測方法についてあれやこれやと考えてきた。結果，非常に良いデータが取れるようになってきたので，このタイミングで進捗をちょっと紹介してみたいと思う。

測定ツールを用いた測定の様子。詳細は後段で

操作遅延をどうやって測るのか？

マズルフラッシュの例

　たとえば，FPSでマウスを左クリックすると銃から弾が出る。そして，銃から弾が出るときには，たいていのゲームで「マズルフラッシュ」として銃口が光る。であれば，マウスの左クリックからマズフラッシュまでの時間経過を計測するのが，おそらく最も確実かつ簡単に操作遅延を測定できるのではなかろうか。
　マズルフラッシュを捉えるためには，画面の明るさ変化を追う必要があるが，これは光学センサーで検出できそうだ。

REVIVE USB（のキットを組み立てたもの）。ビット・トレード・ワンは組み立て済み版も販売しているので，電子工作が苦手という人はそちらを選ぶ手もある

　問題はマウスを左クリックをどう検出するかだが，ビット・トレード・ワンが，USB HID入力デバイスを簡単に自作できるキット「REVIVE USB」を販売しているので，これを使うことにした。

　REVIVE USBは，Microchip Technology製のPICマイコンを搭載するモジュールだ。キーボードやマウス，ゲームパッド，あるいはそれに類する製品を自作するための製品である。
　専用のソフトウェアツールでHID入力デバイスの種類，そして端子とボタンの対応関係を設定のうえ，端子にスイッチを接続すれば，USB HIDデバイスとして機能させられるので，REVIVE USBを使えば，「マウスの左クリックを行うツール」は簡単に作成できる。操作遅延の測定にはうってつけ，というわけだ。

入手したArduino

　時間の測定には，広く利用されているマイコンボード「Arduino Uno R3」（リンクはAmazonアソシエイト，以下 Arduino）を使うことにした。
　データの取り込みから集計までの手間を考えると，Windowsが動くPCや，あるいはLinuxが動くRaspberry Piなどで時間を測定するのが楽なのだが，マルチタスクOSでは「センサーに変化が起きた」といったイベントをリアルタイムで捉えるのが少し面倒だ。というのも，基本的にマルチタスクOSでは多数のタスクにCPU時間を割り当てなければならないからである。

1.8インチカラーの液晶パネルとmicroSDカードスロット，操作用スティック（※写真左手前に見える円柱状のもの）を備える，Adafruit製拡張ボード「1.8" Color TFT Shield w/microSD and Joystick」（リンクはAmazonアソシエイト）も入手。今回はこれをArduinoと組み合わせて使う

　一方，Arduinoのようなマイコンボードだと基本的に1つのタスクしか動いていないので，簡単にマイクロ秒の精度でイベントを捉えることができる。また，Arduinoには「Shield」と呼ばれる拡張ボードが豊富に発売されており，それらを使うことで，microSDカードや液晶パネルを利用できたりといった具合に，周辺機器やライブラリがとても充実している。なので応用プログラムが簡単に作れるのも利点だ。

　REVIVE USBの端子にArduinoのGPIO（General Purpose Input/Output，汎用入出力）を接続すれば，Arduino上のプログラムからマウスの左クリック（＝銃のトリガーを引く）を行うことができる。Arduino用のプログラムを書けるなら，難しいことは何もない。

TEMT6000を搭載するモジュール

　一方，光学センサーでマズルフラッシュを捉えるほうだが，今回はVishay Semiconductors製の可視光センサー「TEMT6000」（※リンクはAmazonアソシエイト）搭載のモジュールを使うことにした。TEMT6000を搭載するモジュールのオリジナルはAdafruit Industries製だが，中国製のコピー品が山ほど出ており，筆者が入手したのもその1つで，製品名は未詳だ。

　いずれにせよ，TEMT6000搭載モジュールを使うにあたっては2つの課題がある。1つは，「可視光センサーをどうやって画面にくっつけて固定するか」だ。
　マズルフラッシュを捉える場合，可視光センサーをできるだけ画面に近づける必要があるため。「マズルフラッシュの最初のフレーム」を捉えるためには，微妙な画面の明るさの変化を捉える必要があり，そのためには画面上の比較的狭い範囲，具体的には銃口周辺の明るさ変化を検出するようにしなければならない。

　また，ややテクニカルな話になるが，価格面で入手しやすい可視光センサーは，TEMT6000を含めて多くが環境光測定向けだ。そのためダイナミックレンジが広く，日中の屋外でようやく測定の上限に達する程度に調整されている。したがって「画面上の微妙な明るさの変化」がもたらす可視光センサーの出力の変化は，とても微細だったりする。
　一方，Arduinoが持つアナログ入力の分解能は1bitあたり約5mVと，かなり粗い。ダイナミックレンジが広いセンサーに対して分解能が粗いアナログ入力だから，ただセンサーをArduinoに接続しただけでは，微細な変化を捉えるのが難しいという問題があり，これがもう1つの課題となる。

　以上の問題をどうしたかだが，第1の課題に対しては，ローテクながら効果的な方法で対処することにした。まず，白い光沢紙で直径12mm，長さ15mmくらいの筒を作り，筒の一端に可視光センサーを取り付ける。そして筒の外からの光を遮断するため，筒の外側に黒いテープを巻く。これで「センサー付きの黒い筒」が完成だ。
　この筒を，ディスプレイ機器上でマズルフラッシュが発生するあたりに，跡を残さず剥がせるテープで貼り付ける。乱暴だが，確実である。

光沢紙で作った筒の一方に可視光センサーを固定し，外側を黒いテープで覆い周辺光を遮断

これをディスプレイ機器のマズルフラッシュが発生するあたりに，剥がせるテープで貼り付ける

　筒を取り付ける画面上の位置は当然のことながらマズルフラッシュの位置となる。FPSの場合は銃の位置が画面上でおおむね固定されているため，マズルフラッシュが生じる画面上の場所も基本的には常に同じとなる。なので，ゲームタイトルが同一であれば常に同じ画面上の場所――貼り直すときに数mmレベルではズレることはあるが――で測定を行うことになる。
　FPS以外のタイトルだと，マズルフラッシュの画面上の場所がそのときどきで変わるケースはあり，測定する画面上の場所が変わると測定結果にも影響を与える可能性が生じうる。そのため画面上のセンサーを取り付ける位置を考慮する必要が出てくるが，それはFPS以外を測定するときに考えることとなるだろう。

OPAMPベースの増幅器を入れた。ちなみにTEMT6000モジュールはフォトトランジスタのエミッタフォロア（＝比較的低インピーダンス出力）だ。OPAMPの出力は言うまでもなく低インピーダンスなので，ノイズの影響は受けづらく，ノイズを気にする必要はあまりない。なのでこんなふうに宙ぶらりんな感じで増幅器を入れても無問題だ

　第2の課題に対しては，TEMT6000モジュールの出力をOPAMP（オペアンプ）で増幅するという選択をした。増幅すれば出力の変化幅が大きくなり，粗いアナログ入力でも微細な変化が捉えられるようになる，というわけである。
　現状，増幅率は11倍で固定しているが，増幅率を調節できるようにすれば，なおいいかな，という気もしている。

　以上を組み合わせたシステム全景は下のような感じだ。Arduino上のプログラムでは，まず銃のトリガーを引く前の画面の明るさを可視光センサーで測定しておき，REVIVE USB経由で銃のトリガーを引いてから画面の明るさが一定の閾値（しきいち）を超えるまでの時間を測定することになる。

システム全景。現状では暫定的にREVIVE USBをブレッドボードに取り付けてジャンパで接続しているが，いずれ適当な箱に入れる予定だ

　閾値は，トリガーを引く前の画面の明るさに対して，％で任意に設定できるようにした。実際にやってみたところ，可視光センサーの出力が10〜20％増加した付近を閾値にするのがほどよいようだ。

　10〜20％ほどという幅を閾値に設けている理由は，アナログ→デジタル変換で原理的に避けられない量子化誤差を考慮する必要があるためだ。
　量子化誤差とは，喩（たと）えるなら3Dグラフィックスで斜めの線に出るジャギーのこと。センサーのアナログ出力値をデジタルに変換するときにも，このジャギーの出現が避けられない。
　画面がやや暗く，可視光センサーの出力電圧がごく小さい場合，閾値をある程度は引き上げおかないと量子化誤差で閾値を超えてしまうため，マズルフラッシュを捉えることができないのである。なので10％〜20％ほどと調節する幅が必要なのだ。

　ちなみにこの10〜20％という値は「Arduinoに対するアナログ入力値の増分」である。前述のとおり，Arduinoへ入力する前段で11倍に増幅しているため，実際には「トリガーを引く前に対して1〜2％増加した程度」という，極めて小さな明るさの変化が閾値となる。なので，いずれにしてもマズルフラッシュを捉えるのに十分な感度を持つと考えている。
　余談気味に続けておくと，先に増幅器の増幅率を調節できるようにしたほうが良さそうと述べたのは，画面が暗い場合にアナログの段階で増幅率を引き上げられるようにしておけば設定の自由度が大きくなるだろう，という意味だったりする。

　なお，Arduino側では，アナログ→デジタル変換に標準の設定で約100マイクロ秒（μs）かかる。正確には計算していないものの，そのほかの処理時間も加味するに，本システムの，操作遅延の時間測定精度は150μ秒程度だろう。
　ディスプレイのリフレッシュレートが仮に500Hzとしても1フレーム2ミリ秒（＝2000マイクロ秒）なので，時間精度は十分すぎるほどだ。

　少し気になるのは，REVIVE USB側で生じる遅延がどれくらいかだが，REVIVE USBのPICマイコンは，12MHzという，十分に高いクロックで動作している。なので，よほどのことがない限り問題になるほど大きな遅延が発生することはないはずである。また，常にREVIVE USBの遅延が一定であれば，それ以外のデバイスの比較を行う際にREVIVE USB側の遅延を考慮する必要はないのも確かだ。
　ちなみに，REVIVE USBに接続しているGPIOはArduino側からGNDに1ミリ秒落としてトリガーを引いている。時間の計測は1ミリ秒落とす直前にスタートさせているので，システムで計測する遅延の時間はトリガーを引く1ミリ秒を加えた時間になる。

※2017年12月28日13：00頃追記
　ビット・トレード・ワンから，REVIVE USBはレポートレート1000Hz，遅延1ms以下を実現しているという連絡があったので記しておきたい。

どんなデータが取れるのか？

　4Gamerではこのシステムを「4Gamer Input and Display Latency Checker」と呼ぶことにするが，本システムで実際に「Counter-Strike: Global Offensive」（以下，CSGO）を使って測定している様子を撮影してみたのが下の動画だ。


　動画では，約2秒に1回，Arduino側のプログラムから自動でトリガーを引いて，操作遅延を測定。その結果をテストシステムの液晶パネル上に表示しつつ，microSDカードにもデータファイルとして保存する。
　現在のところ，テスト開始から自動的に銃を100発撃って100回分の操作遅延をデータファイルに保存するようArduinoのプログラムを作成している。プログラムの仕様上，途中で中断することも可能だ。

　約2秒のインターバルを空けているのは，「トリガーを引く前の明るさに対してセンサー上の値が10〜20％増えるまでの時間」を測っている関係で，マズルフラシュの残光や煙など，余計なものが画面に残っていると正確な測定ができないためである。

　なお，動画では後半で液晶パネルに寄っているが，そこを見てもらうと分かるように，液晶パネルに出てくる遅延の値は毎回少しずつ異なっていて，ぴったり同じ値に揃うことはない。なのでサンプルを100取って，バラツキに対応しようとしているわけだ。

AMDは「Radeon Software Adrenalin Editionで，DirectX 11世代のタイトルに対して最適化を行い，操作遅延を低減させた」と，グラフでアピールしている。本稿で例として使ったCSGOも，AMDのアピール対象になっているタイトルの1つだ

　では，どんなデータが測定できるのかだが，4Gamer Input and Display Latency Checkerがひとまずの完成を見たタイミングで，ちょうどAMDのグラフィックスドライバに大型アップデートが入り，「Radeon Software Adrenalin Edition 17.12.1」以降では操作遅延の低減が謳われているため，今回は動作検証がてら，その実態確認を行ってみることにしよう。

　テストに用いたシステムは表1のとおり。テストにあたっては垂直リフレッシュレート144Hz対応でFreeSyncも利用できるLG Electronics製ディスプレイ「24GM79G-B」を同社の日本法人であるLGエレクトロニクス・ジャパンから貸し出してもらえたので，こちらを用いる。

24GM79G-B
メーカー：LG Electronics
問い合わせ先：LGエレクトロニクス・ジャパン カスタマーセンター
実勢価格：2万8000〜3万2000円程度（税込，2017年12月28日現在）

　というわけで，まずは「どんなデータを測定できるのか」のサンプルとしてグラフ1を示しておきたい。ここでは「Radeon RX Vega 56」（以下，RX Vega 56）用のグラフィックスドライバとして「Radeon Software Crimson ReLive Edition 17.11.4」（以下，Crimson ReLive 17.11.4）を組み合わせ，垂直リフレッシュレート60Hzの設定で，Vsync有効と無効とを切り換えて測定した例だ。取得したデータに頻度分析を行ったうえでグラフ化したものになる。


　グラフの横軸は何ミリ秒（ms）の遅延が計測されているのか，縦軸は当該遅延が100回の試行において何回計測されたのかを示す。
　たとえばVsync無効の場合，45〜50msクラスの操作遅延を最多で60回測定しており，次いで50〜55msの遅延を29回，そして65〜70msの遅延を7回測定しているということがこのグラフから分かる。

　垂直リフレッシュレート60Hzのとき1フレームの時間は約16.7ms。なので，最初のピークである45〜55msと次に大きな山である65〜70msの間ではおおむね1フレーム分の違いがあるわけだ。
　「Vsync無効の場合は画面のリフレッシュに表示が同期しないため（関連記事），遅延も2フレームにわたる広がりが見られ，結果として頻度解析のグラフに2つの山ができる」というのは理屈に合っている。

　一方，Vsync有効の場合は130〜135msの50回をピークとする，歪んだ正規分布といった形のスコアが得られている。
　「正規分布」は高校の数学で習うと思うが，簡単に言うと釣鐘状の分布で，誤差を含む自然界の測定結果に広く見られる分布だ。総じて，多少のバラツキはあれども，理屈に合ったデータだとは言えるだろう。

　詳細にデータを分析したいときには，上のような頻度解析が有用だ。ただ，数多くの測定を比較するときに頻度解析をすべて掲載するとかなり分かりにくくなってしまう。
　そこで，比較を行う場合は，バラツキのある測定値から代表的な値を算出するほうがいいだろう。平均値と中央値，最頻値のいずれを使うかが問題だが，今回は中央値を使うことにする。まず，Vsyncを無効化した場合，測定値は2フレーム前後に渡る広がりを持つが，最頻値だとその広がりが切り捨てられてしまうからというのが理由の1つ。平均値よりも中央値のほうがデータを広がりが反映されやすいというのが1つだ。測定値がおおむね正規分布をとる場合，平均値と中央値，最頻値がいずれもおおむね等しくなるので，問題はないだろうと考えている。

　ただ，中央値だけでは個々の特性は分からない。そこで適宜，個別の頻度解析を示していくことにしたい。
　さて，そのとき，測定対象となるゲームタイトルは，複数回の測定を行う必要があるため，次に挙げる3条件を満たすものが望ましいということになる。

1. しっかりしたマズルフラッシュ描画がある
2. 銃を最低100発は連続して空撃ちできる
3. 銃を空撃ちしている間に敵から襲われない

　1.はともかく2.が成立するには持ち弾が空にならないことが必要で，その条件が満たせるゲームタイトルはかなり少ない。また，空撃ちしている間に敵から逃げる必要があったりするとそれに応じて画面の明るさが変化してしまうため，3.の条件を満たせないタイトルもあまり好ましくはない。

Overwatchにおけるマズルフラッシュの例

　幸いにして，CSGOは練習用のボット戦においてcfgファイルを変更することによって残段数を無限にでき，かつボットも無力化できるため，条件を簡単にクリアできる。
　また，「Overwatch」も，「トレーニング」の「練習場」では，無限に銃を撃つことができ，かつ敵に襲われないので，3条件を満たせる。よって今回はこの2タイトルを用いることにした次第だ。

CSGOとOverwatchで新旧Radeon Softwareの操作遅延を調べる

　では，今回のテストシステムと方法は，実際に目に見える違いを示すことができるのだろうか。前述のとおり，新旧Radeon Softwareの比較を通じ，この点を明らかにしてみたい。基本的には，RX Vega 56を用いて「Radeon Software Adrenalin Edition 17.12.2」とCrimson ReLive 17.11.4を比較しつつ，操作遅延のリファレンス機材として用意した「GeForce GTX 1080 Founders Edition」とも状況を比べてみるといった感じになる。

　テストに用いるディスプレイ設定は以下のとおり。前述のとおり，24GM79G-Bは垂直リフレッシュレートが最大144HzでFreeSyncに対応するため，さまざまな条件設定を行うことが可能となっている。

1. 垂直リフレッシュレート60Hz，Vsync無効
2. 垂直リフレッシュレート60Hz，Vsync有効
3. 垂直リフレッシュレート60Hz，Enhanced SyncまたはFastSync有効
4. 垂直リフレッシュレート144Hz，Vsync無効
5. 垂直リフレッシュレート144Hz，Vsync有効
6. 垂直リフレッシュレート144Hz，Enhanced SyncまたはFastSync有効
7. FreeSync有効，Vsync無効（※RX Vega 56のみ）
8. FreeSync有効，Vsync有効（※RX Vega 56のみ）

Radeon Settingsの「垂直リフレッシュを待機」から「強化された同期」を選択することでEnhanced Syncは有効化できる

　念のために説明しておくと，Enhanced Syncは通常のディスプレイでテアリングの発生を抑えつつ操作遅延の低減を実現できるとされるAMDの技術で，FastSyncはそのNVIDIA版――公正のため記しておくと，導入したのはNVIDIAが先――である。なので，Enhanced SyncおよびFastSyncを有効化したときの操作遅延も調べることになる。

　なお，Enhanced Syncは一般的なディスプレイでテアリングを抑えつつ操作遅延を低減する技術となるため，GPUのレンダリングにディスプレイのリフレッシュを同期させる「FreeSync」とは異なる。また，Enhanced SyncとFreeSyncを同時に有効化することはできず，そもそも意味がない。

Radeon Settingsの「ディスプレイ」で，FreeSyncの有効/無効切り替えを行える

　そのFreeSyncは，理屈の上ではテアリングがなく操作遅延も最短になるはずだ。その点ではライバルのNVDIAが推すG-SYNCと同じである。ただ，FreeSyncではVsync無効時と有効時とで挙動が変わるというのが，G-SYNCとは異なるところだ。
　FreeSyncでVsyncを無効化にした場合，「ディスプレイが対応するリフレッシュレートの上限」をGPUのレンダリング速度が超えたとき，フレームの描画はリフレッシュレートに同期させない。そのため，ディスプレイが対応するリフレッシュレートの上限を超えるフレームレートに達するとテアリングが生じることになる。
　一方Vsyncを有効化した場合，「ディスプレイが対応するリフレッシュレートの上限」をGPUのレンダリング速度が超えたとき，フレームの描画はディスプレイのリフレッシュレートに同期する。つまり，リフレッシュレート以上にフレームの描画速度が上がることはなく，テアリングも生じないわけだ。

　いずれにしても，これまでのAMDの説明から推測するに，リフレッシュレートの上限をGPUのレンダリング速度が超えない限り，FreeSync使用時の操作遅延に違いはないはずだ。ただ今回はテストのためのテストでもあるので，FreeSyncを有効化しつつ，Vsyncの無効/有効も切り換えて，双方でテストすることになる。

　ということでグラフ2は，CSGOで上記8条件の操作遅延を100回計測し，その中央値を算出して比較したものとなる。グラフ中，「Enhanced SyncおよびFastSync」は「ES/FS」と略記しているので，その点はご注意を。


　まず新旧Radeon Softwareだが，Adrenalin 17.12.1で驚くほど遅延状況が改善していると断言してしまっていい。たとえば垂直リフレッシュレート60HzかつVsync無効の条件だと，Crimson ReLive 17.11.4で中央値は約50msだったものが，Adrenalin 17.12.1では約19msになっているのだ。どんなに厳しく見ても1フレーム分は確実に操作遅延の低減を果たしていると言っていい。
　さらに強烈なのはEnhanced Sync有効時で，Crimson ReLive 17.11.4ではほぼ「機能していない」レベルだったのだが，FastSyncと同等レベルの速度性能を獲得するに至っている。

　垂直リフレッシュレートリフレッシュレート144Hz時にEnhanced Syncを有効化したときの遅延状況は約25msで，これはFast Sync有効時の約42msより速い。……というか，垂直リフレッシュレート144Hz時のFast Syncが明らかに遅い。垂直リフレッシュレート60Hzでは十分に速いのに，144Hz時はVsync有効時と大差ないレベルになってしまうのだ。Enhanced Syncを有効化することでわずかながら逆に遅くなるCrimson ReLive 17.11.4よりはマシとも言えるが，FastSyncにはまだ改良の余地があるように思われる。

　操作遅延に関して，Adrenalin 17.12.2とCrimson ReLive 17.11.4の間でどのような違いが生じているかを，少し実測値で確認しておこう。グラフ3は垂直リフレッシュレート60Hz，Vsync有効時の実測値を頻度解析したものだ。
　Adrenalin 17.12.2では95〜100msの間の遅延が80回と全測定数の8割を占めているのに対して，Crimson ReLive 17.11.4では130〜135msの50回を中心として，正規分布的な広がりを見せている。およそ2フレーム分（＝16.7ms×2程度）はAdrenalin 17.12.2で操作遅延が低減していると見ていいだろう。


　グラフ4はちょっと見方を変えて，GPUをRX Vega 56，垂直リフレッシュレートを60Hzで固定した条件から，Adrenalin 17.12.2を導入してEnhanced Syncを有効化した状態と，Crimson ReLive 17.11.4でEnhanced Syncを有効化した状態とVsyncを有効化した状態の3条件における測定値を1つのグラフにまとめたものだ。

　まず，Crimson ReLive 17.11.4の2条件で，Enhanced Syncを有効化したときと，Vsyncを有効化したときの頻度分布には大きな違いがないと分かる。強いて言えば，Enhanced Syncを有効化するとむしろ1フレームほど遅れてしまっており，Crimson ReLive 17.11.4でEnhanced SyncがAMDの目論みどおり機能していないのが気になった。
　一方，Adrenalin 17.12.2導入してEnhanced Syncを有効化すると，30〜35msが最多の65回を記録しており，Crimson ReLive 17.11.4とは大きな開きがある。Adrenalin 17.12.2でEnhanced Syncが前宣伝どおりの効果を発揮した，というわけである。


　以上，4Gamer Input and Display Latency Checkerを使うことで，「新世代グラフィックスドライバの採用による操作遅延低減」や，「GPUメーカー独自のディスプレイ同期技術が有効か否か」といったところを確認することができた。せっかくなので追記しておくと，Adrenalin 17.12.2導入時の操作遅延はリファレンス機材と比べても明らかに低く，極めて優秀と言えるレベルだ。

　ただし，すべてのタイトルで理想的な効果が得られるわけではないということを示したのが，グラフ5にスコアをまとめたOverwatchの結果である。
　Radeonシリーズのユーザーなら体験的に知っていると思うが，Overwatchは，Radeonとの相性があまりよろしくない。Radeon Software Crimson ReLive Edition時代にはEnhanced Syncを有効化するとそもそもゲームが起動しないという問題があった。なのでスコアはN/Aとしている。

　また，テスト結果を見る限り，Enhanced SyncやFreeSyncが正常に機能しているかはかなり微妙。付け加えると，Adrenalin 17.12.2を導入することによる操作遅延の劇的な改善もないようだ。


　グラフ6は垂直リフレッシュレート60Hz，Vsync有効時における実測値の頻度解析だが，Crimson ReLive 17.11.4に対してAdrenalin 17.12.1で操作遅延が改善しているとは言いがたい。測定値のバラツキは減っているのを確認できるので，何らかの違いがあるのは確かだが，ことOverwatchに向けたRadeon Softwareの最適化具合は正直「まだまだ」といったところになるだろう。

ディスプレイ遅延検証にも光明。「操作遅延」の観点からテストが可能になる（はず）

　CSGOではAdrenalin 17.12.2で素晴らしい操作遅延効果が得られる一方，Overwatchではさっぱりであるといった具合に，4Gamer Input and Display Latency Checkerを導入することで，操作遅延に関する分かりやすいテスト結果が得られた。

　操作遅延の測定ができるようになったことで，今後，4Gamer Input and Display Latency Checkerによるさまざまな検証が可能になるだろう。4Gamerとして最も期待しているのは，ディスプレイ自体の遅延測定だ。

　4Gamerではこれまで，DVI-Dのスプリッタを使ってグラフィックスカードの出力を2分配し，リファレンスディスプレイとテスト対象機を高速撮影してディスプレイの遅延を評価してきた。
　しかし，今日（こんにち）のゲーマー向けディスプレイ市場では，接続インタフェースとしてDisplayPort 1.4とHDMI 2.0が主流となり，垂直リフレッシュレートも144Hzや240Hzといった高水準が当たり前になってきている。DisplayPort 1.2以降でサポートされる高い垂直リフレッシュレートに対応するスプリッタはなかなか手に入らないため，高速撮影による比較検証は難しくなっていたというのが現状だ。

　しかし，4Gamer Input and Display Latency Checkerを使えば，前述のとおり，仮に垂直リフレッシュレートが500Hzまで達したとしても，有意な測定データを取得できる可能性が高い（※まだディスプレイのテストを実施していないので断言はしないが）。
　これまで行えなかった，高速なゲーマー向けディスプレイの性能検証が可能になるはずである。

　また，グラフィックスカードやグラフィックスドライバ，あるいはCPUによる操作遅延の違いといったことすらも，おそらく検証可能だ。操作遅延に着目して，ゲーマー向けデバイスの性能評価が行えるようになる意味は大きいだろう。
　実際，今回のテストでは，メーカーが操作遅延の低減を謳っていても，ゲームタイトル次第ではまったく効果が得られないケースがあるというデータを取得できている。なので，「操作遅延の測定が可能なゲームタイトル」の数を増やすことが4Gamer側として今後の課題となる。


　前述した3条件を満たすゲームタイトルは少ないと思われるものの，残弾数が0になるまで撃ったらいったんゲームから抜けて，あらためて撃ち直すという測定を行えば，なんとかなるのではなかろうか。幅広いゲームタイトルで測定できるよういろいろと工夫したうえで，実際のハードウェアレビューで活用していきたいと考えている。