Sta-sta-stattering、またはゲーム内でマイクロフリーズが発生する場所とその対処方法

想像してみてください。ここで、お気に入りのゲームの新しい部分を待っていると、ついに登場します。特にこのビジネスでは、PCを更新しました。最新のCPUとGPUをインストールし、RAMの容量を増やし、ハードドライブをSSDに置き換えました。これで、最初のロード画面から最後まで、ゲームがシルクのようにスムーズに実行されるはずです。



ここでは、以前に支払った予約注文をダウンロードします。インストールが終了し、ゲームを開始します。すべてが順調に進んでいます。ゲームは60FPSのフレームレートで動作します。または、少なくとも、GPUオーバーレイのフレームカウンターが示すことです。しかし、何かがうまくいかない。マウスを前後に動かすと、ゲームがフリーズしていることに気づきます。



これはどのように可能ですか？ 60 FPSで他にどのようなフリーズがありますか？



自分で出くわすまではばかげているように見えるかもしれません。あなたがそのようなフリーズに出会ったなら、あなたはおそらくすでにそれらを嫌うことができたでしょう。



これらは遅れではありません。低フレームレートではありません。これはボロボロです。高FPSと理想的な超高速構成を備えています。



それは何ですか、それはどこから来ましたか、そしてそれを取り除く方法はありますか？今それを理解しましょう。







70年代に最初のアーケードマシンが導入されて以来、ビデオゲームは60FPSで実行されています。通常、ゲームはディスプレイと同じ速度で実行する必要があると想定されています。 3Dゲームが普及して初めて、より低いフレームレートに直面して採用する必要がありました。 「3Dカード」（現在は「GPU」と呼ばれています）がソフトウェアレンダリングに取って代わり始めた90年代に、人々は毎秒20フレームで再生し、35FPSはすでに深刻なネットワーク競争の頻度と見なされていました。



これで、もちろん60FPSで飛行できる超高速の車ができました。しかし...これまで以上にパフォーマンスに不満があるようです。これはどのように可能ですか？



ゲームの速度が十分でないわけではありません。そして、それらが高性能でもフリーズするという事実。



ゲームフォーラムを閲覧すると、おそらく見出しに次のようなものが表示されます





。PCゲーマーは、フレームレートの問題がなくても、ゲームがボロボロになると不満を言うことがよくあります。



これらは孤立したケースであると想定できますが、そのような想定はGoogle検索統計によって払拭されています。





過去5年間で、スタッターはパフォーマンスよりも（比較的）問題になっています。



（これらは相対値であることに注意してください。一般的なフレームレートよりもスタッターに関する情報を頻繁に探しているわけではありません。フレームレートの検索数は同じですが、特に最近では、スタッターの検索が一般的になっています。 ）

よろめきの理由を探す10年

患者は間違いなく生きています。彼はただ頻繁にフレットを鳴らします。



著者は、2003年にSerious Sam 2の作業中にこの問題に最初に遭遇しました。人々は、空のレベルでのテスト中に画面とマウスの動きがスムーズでなかったケースを報告し始めました。これには、フレームレートグラフの非常に特殊なパターンが伴い、開発チームはこれを「ハートビート」と呼びました。



最初に考えたのは、コードのどこかにバグが潜んでいたが、誰もそれを見つけることができなかったということでした。問題はランダムに現れたり消えたりしたように見えました-ゲームを再起動したとき、コンピューターを再起動したとき...しかし、パフォーマンスパラメータを変更する価値があり、それは消えました。その後、パラメータを元に戻すことができ、すべてが完全に機能し続けました。ゴーストの問題。



明らかに、問題はサムだけではありませんでした。他のゲームを起動したときも同じように表示され、ドライバーに問題があったことを示しています。しかし、スタッターはGPUのメーカーに依存していませんでした。さまざまなAPI（OpenGL、DirectX 9、DirectX 11 ...）でも発生しました。唯一残っていたのは、一部のマシンやゲームシーンでスタッターがあちこちに現れたことです。



新しいゲームのリリースに伴い、この問題は現れたり消えたりし続けました。以前は、これは一部のユーザーにのみ影響し、すべてがテクニカルサポートからの一部のパフォーマンスパラメータの変更要求に限定されていました。これは、役立つ場合もあれば、そうでない場合もあります。



その後、2013年初頭の突然のある美しい冬の日、Croteamのメンバーは、当時比較的一貫して再現できるこの問題の別の例を発見しました。今回は、Serious Sam3のレベルの1つです。彼らはそのシーンを長い間いじり、突然夜が明けるまで続けました。それはとても単純でした-それが10年間世間の目を逃れたのも不思議ではありません。



ゲームエンジンの簡単なオプションを1つ変更するだけで、この問題を解決することができました。ただし、ソリューションには実際にははるかに多くの時間と労力が必要であることがすぐに明らかになりました。また、特定のチームだけでなく、ゲームエコシステム全体（GPUドライバー開発者、APIメンテナンススペシャリスト、OSベンダー）からも参加しています。

この間ずっと何が起こっているのか

これは、60FPSでもゲームの速度が低下した場合の外観です。現代のゲームをプレイするのと同じようなことを経験した可能性があります。おそらく最初に思うのは、ゲームが最適化されていないということです。さて、この理論をもう一度見てみましょう。



ゲームが「遅すぎる」場合は、ある時点で1つのフレームを十分に速くレンダリングできず、モニターに前のフレームを再度表示する必要があることを意味します。したがって、毎秒60フレームでビデオを撮影すると、「ドロップされたフレーム」が表示されます。次のフレームが時間内に表示されなかったため、同じフレームが2回表示されました。



ただし、これはアニメーション全体を再生する場合にのみ発生します。フレームごとに調べてみると、ギャップはありません。

これはどのように可能ですか？

これを詳しく見てみましょう。以下は、理想的なスムーズビデオとステージングされたビデオを並べて比較したもの





です。正確なタイミングの6つの連続したフレーム。上-正しく配置されたフレーム、下-スタッターのあるフレーム。



ここで2つのことがわかります。1つは、実際には同じ速度で動作することです。新しいフレームが上に表示されると（正しい）、次に新しいフレームが下に表示されます（スタタリング）。第二に、何らかの理由で、それらは少し異なって動くように見えます-画像の中央に、より大きな時分割とより小さな時分割の間で変動する顕著な「ギャップ」があります。



最も注意深い人は、別の奇妙な詳細に気付くかもしれません。下の画像はおそらく「遅い」...実際には正しい画像より「進んでいる」のです。不思議ですね。



いくつかの連続するフレームとそのタイミングを見ると、別の興味深いことがわかります。最初の2つのフレームは完全に同期していますが、3番目のフレームでは、「遅い」ビデオのツリーが「正しい」ビデオのツリーよりも大幅に進んでいます。ビデオ（赤丸）..。また、このフレームに明らかに時間がかかったことにも気付くでしょう（黄色の丸で囲んだ部分）。



待って、待って...しかし、ビデオが「遅く」、フレームが「長くかかった」場合、どうすれば先に進むことができますか？



詳細な説明を理解するには、まず、最新のゲームやその他の3Dアプリケーションが一般的にアニメーションとレンダリングを実行する方法を理解する必要があります。

フレーム同期の簡単な歴史

はるか昔、はるか遠くの銀河系で...開発者が最初のビデオゲームを作成したとき、彼らは通常、ディスプレイが実行された正確なフレームレートに基づいて作成しました。テレビが60Hzで動作するNTSCリージョンでは、これは毎秒60フレームを意味し、テレビが50 Hzで動作するPAL / SECAMリージョンでは、毎秒50フレームを意味します。



ほとんどのゲームは、固定ハードウェアで実行される非常に単純な概念でした。通常、アーケードコンソール、またはZX Spectrum、C64、Atari ST、Amstrad CPC 464、Amigaなどの有名な「ホームマイクロコンピューター」です。特定のマシンと特定のフレームレートのゲームでは、開発者はフレームレートがどこにも低下しないことを常に100％確信できます。



オブジェクトの速度も「人員」単位で保存されました。したがって、キャラクターが1秒間に何ピクセル移動するかではなく、フレーム内のピクセル数を知る必要がありました。たとえば、セガジェネシスのソニックザヘッジホッグでは、この速度はフレームあたり16ピクセルです。多くのゲームには、PALリージョンとNTSCリージョンに別々のバージョンがあり、アニメーションはそれぞれ50FPSと60FPS用に手描きされていました。実際、他のフレームレートで作業することは不可能でした。



また、ハードウェアが拡張およびアップグレードされ続けるPCなど、時間の経過とともにゲームがより多様なデバイスで実行されるようになったため、ゲームが実行されるフレームレートを正確に知ることは不可能でした。この事実は、ゲーム自体がより複雑で予測不可能になったという事実によってさらに複雑になりました。これは、シーンの複雑さに大きな違いがあり、場合によってはプレーヤー自身によって決定される3Dゲームで特に顕著です。たとえば、誰もが燃料バレルのスタックを撃つことが大好きで、カラフルな一連の爆発を引き起こします...そしてフレームレートの必然的な低下を引き起こします。しかし、それは楽しいので、誰も本当に気にしません。



したがって、1つのフレームをモデル化してレンダリングするのにかかる時間を予測することは困難です。 （最近のコンソールでは、ハードウェアは固定されていると想定できますが、ゲーム自体は依然として非常に予測不可能で複雑です。）



ゲームがどのフレームレートで動作するかわからない場合は、現在の周波数フレームを測定する必要があります。ゲームの物理学とアニメーションの速度を常に適応させます。 1つのフレームに1/60秒（16.67ms）かかり、キャラクターが10m / sで実行されている場合、各フレームで1/6メートル移動します。しかし、フレームが突然1/30秒（33.33ミリ秒）かかり始めた場合は、キャラクターをフレームごとに1/3メートル（2倍「速く」）移動させて、同じ見かけで動き続けるようにする必要があります。速度。



どうやってアレンジするの？原則として、ゲームは隣接するフレームの開始時に時間を測定し、差を計算します。これはかなり単純な方法ですが、非常にうまく機能します。



むしろ、以前は非常にうまく機能していました。90年代に、35 FPSがどの速度であるかが考慮されたとき、人々はそれに満足していました。しかし、当時、ビデオカードはPCのそれほど重要な部分ではなく、中央処理装置が画面上で発生したすべてのことを制御していました。3Dアクセラレータがない場合は、それ自体でオブジェクトを描画することもできます。したがって、彼は彼らがいつ画面に当たるかを正確に知っていました。

今日の状況

時間の経過とともに、ますます洗練されたGPUが登場し始め、必然的にそれらはますます「非同期」になりました。つまり、CPUがGPUに画面に何かを描画するように指示すると、GPUはそのコマンドをバッファーに格納するだけなので、GPUがレンダリングしている間もCPUは続行できます。最終的に、これは、フレームの終わりが来るとCPUがGPUに通知する状況につながり、GPUはこれをデータに格納している間、実際には優先事項とは見なしません-結局のところ、それはまだです以前に発行されたコマンドの一部を処理しています...以前にロードされたすべてのことを実行した場合にのみ、フレームが画面に表示されます。



したがって、ゲームが2つの連続するフレームの先頭のタイムスタンプを差し引いて時間を計算しようとすると、率直に言って、これの関連性は非常に疑わしいものになります。それでは、例に戻りましょう。そこには次のフレームがありました





。正確なタイミングの6つの連続したフレーム。上の行は正しく、下の行にはスタッター効果があります。



最初の2つのフレームでは、フレーム時間は16.67ms（または1/60秒）であり、カメラは大文字と小文字で同じ量だけ移動するため、ツリーは同期しています。 3番目のフレーム（以下、スタッターあり）で、ゲームはフレーム時間が24.8ミリ秒（つまり、1/60秒以上）であることを確認したため、フレームレートが低下したと考え、急いで追いつきます。欠落しています...次のフレームで時間はわずか10.7ミリ秒であることがわかりました。これにより、カメラの速度が低下し、ツリーが多かれ少なかれ再び同期されます。



どうしたの？ゲームで測定されるフレーム時間は、さまざまな要因によって変動します。特に、PCのような忙しいマルチタスクシステムではそうです。したがって、ある時点で、ゲームは周波数が60 FPSから低下したと想定し、より低いフレームレート用に設計されたアニメーションフレームを生成します。ただし、GPUは非同期であるため、常に同じ60フレーム/秒に戻ります。



これは途方に暮れています-実際の正しい固定フレームレートで表示される可変フレームレート（心拍数）に対して生成されたアニメーション。



したがって、本質的には、問題はないと想定できます。すべてが順調に進んでおり、ゲームはそれを認識していません。



これで、記事の冒頭で話したことがわかります。問題の原因が最終的に解明されたら（これは問題の幻想であることがわかっていますが、実際には問題はありませんよね？）、次の魔法の薬を適用できます。



このピルは何ですか？Serious Engineでは、sim_fSyncRate = 60として示されます。簡単に言うと、これは、「このすべてのシェナニガンを完全に無視し、常に安定した60フレーム/秒を測定するふりをする」ことを意味し ます。そして、すべてが最初からスムーズに機能したという理由だけで、すべてがスムーズに実行されます！述べた唯一の理由は、アニメーションのタイミングが間違っていたためです。



そして、それはすべてですか？

だから解決策はとても簡単ですか？

残念だけど違う。それはただのテストでした。実際の条件でフレームレートの測定を停止し、常に60 FPSに等しいと単純に仮定した場合、フレームレートが60を下回ると、PCでは、バックグラウンドで実行されているプログラム、エネルギーなどの理由で遅かれ早かれ低下します。誰が知っている保存または過熱保護-そうすればすべてが遅くなります。



したがって、フレーム時間を測定すると、スタッターが発生し、そうでない場合は、ある時点ですべてが遅くなる可能性があります。そして、何？



実際の解決策は、フレームのレンダリングの開始/終了時間ではなく、画像が画面に表示される時間を測定することです。



しかし、フレームが実際に画面に表示されていることをゲームはどのようにして知ることができますか？



まさか：現時点ではこれは不可能です。



奇妙ですが、本当です。これがすべてのグラフィックスAPIのコア機能であることが期待されます。しかし、違います。これ以外のすべての側面で変更が加えられています。フレームが実際に画面に表示されるタイミングを確実に知る方法はありません。レンダリングがいつ終了したかを確認できます。しかし、これは表示時間と同じではありません。

それで？

まあ、それはそれほど悪くはありません。多くの人々が、さまざまなAPIの正しいフレーム同期のサポートの実装に積極的に取り組んでいます。Vulkan APIには、この概念を実装した確かな実績を持つVK_GOOGLE_display_timingという拡張機能がすでにありますが、これは限られた数のデバイスでのみ使用できます。



同様のより良いソリューションを提供するための作業が進行中です。私は、すべての主要なグラフィックスAPIですでにそれを信じたいと思います。いつ？問題はさまざまなOSサブシステムに深く関わっているため、言うのは難しいです。



ただし、まもなく一般に公開されることを願っています。

さまざまな警告およびその他の詳細

これで本文の終わりと仮定します。以下のセクションは、互いにほとんど独立している「ボーナス機能」です。

"作曲"

それはすりガラス効果ですか？ええ、そういうわけで私達は作曲家を持たなければなりません。かなり重要ですね。 コンポーザーとも



呼ばれるコンポジットウィンドウマネージャーと呼ばれる概念が舞台裏で関わっています 。これは現在すべてのOSに存在するシステムであり、ウィンドウを透明にしたり、背景をぼかしたり、影を付けたりすることができます。コンポーザーはさらに進んで、プログラムウィンドウを3Dで表示できます。これを行うために、コンポーザーはフレームの最後の部分を制御し、モニターに到達する直前にそれをどうするかを決定します。



一部のオペレーティングシステムでは、コンポーザーをフルスクリーンモードで無効にすることができます。しかし、これが常に可能であるとは限りません。そのような場合でも、ウィンドウモードでゲームを実行することはできませんか？

電力および熱管理とレンダリングの複雑さ

また、最新のCPUとGPUは固定周波数で動作しないという事実も考慮に入れる必要がありますが、どちらにも負荷と現在の温度に応じて速度を上下に調整するシステムがあります。したがって、ゲームは、フレーム間で同じ速度になると単純に想定することはできません。一方、オペレーティングシステムとドライバーは、ゲームがフレームごとに同じ量の作業を行うことを期待することはできません。2者間の複雑な通信システムは、これらすべてを考慮に入れるように設計する必要があります。

私たちはただ...

できませんでした。:)通常、GPU時間測定は、表示時間の代わりに提供されます。ただし、これは、コンポーザーの存在と、GPUレンダリングタイマーのいずれも実際にはディスプレイの更新と直接同期しないという事実を考慮していません。完璧なアニメーションを作成するには、レンダリングが終了したときではなく、画像がいつ表示されたかを正確に知る必要があります。