半年ほど前にゲームのタイトル毎の描画遅延を測定する手法を紹介しました．
#LogicalGaming: ゲーム毎の描画遅延を測定してみる今回はその測定手法を用いて，別のことを調べます．
今回は，「極限まで処理が簡略化されたゲームの描画遅延はどれくらいなのか？」という事を測ります．
これは，HIDデバイスの入力が，
PC内のUSBホスト → OS(CPU) → ゲーム → グラフィックカード → ディスプレイ
と処理されていく時の最短時間を知ることが出来ます．この最短時間は，ゲームエンジンを描画遅延を意識して書いた時，そのゲームエンジンが到達できる最も低遅延な時間とも言えます．また，ゲームエンジンを最適化しても，これ以下の描画遅延を実現するのは難しいということになります．
プログラム
極限まで処理が簡略化されたゲームとして用意したプログラムは，今年始めに用意した自作プログラムです．SDL(Simple DirectMedia Layer)というマルチメディアライブラリを使用してOpenGL APIを制御します．このプログラムは，マウスカーソルの移動のX軸が右方向なら赤，左なら緑を画面全体に描画します．他にはフレームレートの計測と，ESCキーが押されたら終了する処理のみです．
1フレーム(1ループ)が20行程度で書かれており，初期化が終了すればノートPCで走らせても1000fps以上出る非常に軽いプログラムです．
時代遅れになりつつある私のリグでも6200fps程度出ます(Intel Core i7 2600，NVIDIA GTX 670)．
フレームレートが約6200fpsとすると，プログラム自体が持ちうる遅延は0.16ms程度ですので，遅延は非常に小さいとして無視できます．
つまり，上述の最短時間からゲームの項を削除して考える事が出来ます．
PC内のUSBホスト → OS(CPU) → ゲーム → グラフィックカード → ディスプレイ
USBホスト，OS，グラフィックカードあたりは生半可な手法では遅延を削減出来そうな設定は難しいですので，あとは「ディスプレイを遅延の少ない機種に買い換える」程度しかユーザーサイドで工夫できる場所がないということになります．
結果
右端のBaselineのラベルが付いたものが，今回紹介したプログラムの描画遅延時間です．
また，一般的なFPSタイトルは演算や描画処理などで，さらに4～10ms程度の時間が必要になると分かります．この時間は，エンジン内の描画処理の順序の工夫等で縮められるのでしょうか．描画遅延の削減を売りにしたエンジンとか出れば面白そうですね．
ゲームエンジンは，フレームレートが特にフォーカスされることが多いですが，描画遅延に対してもより一層注目が集まると，この差は徐々に埋まっていくかも知れませんね．
