アセットにカスタムメモリ管理が必要なのはなぜですか？

ゲームプログラミングに関連するほとんどすべてのリソース、特に3Dオープンワールドゲームでは、ディスク、システムメモリ、ビデオメモリとの間でアセットを常にアンロードおよびリロードする必要がある方法について説明しています。コンソールには、オーバーフローの可能性に対処できない非常に単純なメモリ管理スキームがあるため、これを理解できます。

ただし、PCでは状況が大きく異なります。システムメモリ用にOSによって提供される仮想メモリがあり、グラフィックドライバがCPUからGPUへのスワッピングを処理します。それでは、一度にすべてをロードするだけでは不十分であり、プリフェッチのみを処理し、必要なアセットがスワップされている間はブロックされないようにする必要があるのはなぜですか？

これは、すべてがのように単純に割り当てられていると言っているのではありませんmalloc。すべてが隣接し、キャッシュ一貫性が保たれます。とにかく手動でページを出し入れすることを心配する必要がない場合は、メモリアクセスを効率的にする方が間違いなく簡単です...

更新：

非同期バッファー転送に少し読み込んだ後、グラフィックスドライバーが自動的にメモリをページインおよびページアウトする方法が最適ではないことがわかりました。これはCPUリソースにも当てはまりますか。つまり、仮想メモリが存在する場合でも、特定のリソースをいつロードおよびアンロードするかを常に手動で管理する方が良いでしょうか。

現代のオープンワールドゲームは、単にメモリに収まりません。32ビットOSを使用するゲーマーの数が多いため、ほとんどのゲームは依然として32ビットであり、32ビットプロセスは最大で一度に4GBのアドレス指定メモリしか（仮想メモリとは無関係に）持つことができますが、現実的には2-3 GBに制限されています。断片化のトスと、一度にメモリ内に保持できる実際の使用可能なオブジェクトの量は、大規模な環境に必要な合計データよりもかなり小さくなります。64ビットOSであっても、エンドユーザーとの最大の互換性を確保するために、メモリが4GBだけの低スペックマシンを対象にする必要があることがよくあります。モバイルデバイス、WiiUなどの「電力不足」のハードウェアなどを忘れないでください。開発者は、大規模なゲームPCリグよりもはるかに多くをターゲットにする必要があります。

仮想メモリは解決策ではありません。1つ目はアドレス空間の制限を無効にせず、また最適ではないためです。OSは、不都合なときに、または不都合な方法でページアウトできます。これは、休止状態が最初に発生したときにOSによって処理された問題でした。プロセスをディスクにページアウトしてからページインして戻すことは、アプリケーションが明示的にリソースをストリームインして戻すよりもかなり遅い場合がありました。システムのメモリが不足している場合でも、ページがページアウトされ、問題が発生します。ディスク、およびシステムが応答しなくなるWM / explorer.exeを実行するために必要な重要なものがページアウトされます。仮想メモリは、数十年前にシステムにRAMがほとんどなく、メモリとディスクの速度のギャップがはるかに小さかった問題に対して考案されたソリューションでした。今日も' s最速のSSDは、安価なRAMや低速のRAMの速度のほんの一部であり、仮想RAMとしてディスクを使用できるふりをしようとすることは、もはや最良のアイデアではありません。これは、一部の人々が反対のことを行い、ファイルシステムをRAMディスクにロードする時代です。仮想メモリの作成につながった制約はもう当てはまりません。

ディスクの問題は別として、カスタムリソース管理は依然としてゲーム開発の大きな部分を占めています。デバッグフックから断片化の問題、複雑なリソースのインテリジェントストリーミングまで、全世界が無限に大きなビットボックスであると偽るのは現実的ではありません。

32ビットゲームの場合、ほとんどのゲームはさまざまな理由で発生するため、片面DVD（4.3GB）で提供されるゲームでも、32ビットアドレススペースに収めることができるコンテンツがはるかに多くなっています。そして、それはコンテンツがディスク上で圧縮されておらず、完全に最適であると仮定して、すべてを一度に連続したアドレス空間アプローチにロードします。現在、多くのゲームは複数のDVDで提供されており、10GBのコンテンツを簡単に超えることができます。私のPCでの経験では、アドレススペースが2 GBに近づくと割り当てが失敗し始め、ユーザーの物理メモリの量に関係なく、ハードリミットになります。

エンジンが64ビットに対応している場合、64ビットにジャンプすると、そのハード制限はなくなり、有効なソフト制限に置き換えられます-仮想メモリのスワップが発生し始めるとすぐに、ゲームのパフォーマンスが低下します受け入れられない。メインプロセスがメモリがページインされるのを待たなければならない場合、フレームレートが途切れてグリッチが発生します。仮想メモリはそれを透過的にするかもしれませんが、それはそれを実行可能にしません。そのメモリをディスクから戻すには物理的に時間がかかり、待機している間にゲームが停止します。回避することは可能ですが（すぐに必要になることがわかっているメモリページをバックグラウンドでプリフェッチすることで）、これは困難で信頼性の低いプロセスであり、パフォーマンスに影響を与えます。

ディスクにスワップアウトするページを決定するためのOSのアルゴリズムには、ゲームと、次に必要になる可能性があるものについての知識がありません。さらに、OSは、OS自体だけでなく、ゲームと同時に実行されている他のアプリケーションもサポートする必要があります。ページがディスクから返されている間、ストールする必要があることはパフォーマンスの大きな打撃であり、ゲーム、別のアプリケーション、またはOSのいずれであっても、ゲームのパフォーマンスは大幅に低下します。

したがって、メモリ制限がソフトかハードかに関係なく、メモリはまだ制限されています。ただし、パフォーマンスの制限に達することなく、一度にすべてをロードできたとしても、次のような理由がありません。

1. ゲームは、開始時にすべてをロードして常駐させるだけなので、ロードしてインタラクティブな状態になるまでに必要な時間ははるかに長くなります。ハードディスクから約150MB /秒をロードでき、最速のDVDドライブ（24x）でも33MB /秒でロードできます。つまり、4.3GB DVD相当のコンテンツの例では、HDDからのロードに少なくとも30秒、DVDからのロードに133秒以上かかります。これらは許容できないほど長いロード時間です。

2. ゲームは正当化されるよりもはるかに多くのメモリを必要とします。一度にコンテンツの10％しか表示されない場合、残りの常駐者を保持することは単に無駄であり、ユーザーがそのメモリを他の何かに使用することを防ぎます。ユーザーは一般に、適切に実行するために過度に大量のメモリを必要とするゲームを許しません。

バックグラウンドで、またはロード画面で同期的に、ディスクからアセットを動的にストリーミングすることで、ごくわずかな労力でユーザーのマイナーなデメリットのみを使用して、メモリの使用をはるかに効率的にすることができます。しかし、これは最適化であり、他の最適化と同様に、適用しようとするほど、収益は減少します。ある時点で、何かを常駐させるためのメモリフットプリントの増加は、ロードする必要なくそこに存在することで得られる利点よりも重要です。ただし、その時点に到達するまでは、必要なときに必要なものだけをロードすることをお勧めします。

非常に一般的かつ単純に言えば、仮想メモリ実装の詳細を考慮せずに、開発者は常にVM実装に欠けている洞察力に関する知識を持っています。

開発者はいつでも「このオーディオファイルをロードする必要はありません。内部の音楽はゲームオーバースクリーンでのみ使用されます」と言うことができます。ゲームオーバースクリーンの直後に、開発者は「物理メモリにこのオーディオクリップはもう必要ありません。このゲームオーバースクリーンでのみ使用されます。」と言うことができます。

OSにはそのような先見の明はありません。しばらくの間アクセスされなかったために、一部のオーディオクリップが物理メモリで不要になったことを、後で多くのページフォールトによって把握できる場合があります。しかし、先見性を後知恵に変えると、多くのページフォールトが発生し、多くのページフォールトは、ビデオゲームと同様にタイムクリティカルなソフトウェアのフレームレートの中断につながります。そこでは、そのような問題を回避したい場合、開発者の先見性が本当に役立ちます。

そして、それはハードウェアとソフトウェアに関係なく概念的に当てはまります。メモリ内のページングが高価であると仮定すると、開発者の洞察は常にその費用の削減に役立ちます。

さらに広い意味で言えば、ハードウェアデザイナー、コンパイラデザイナー、OS /ドライバーデザイナー、アプリケーション開発者の間には、終わりのないサイクルがあります。ハードウェア/コンパイラ/ OS /ドライバの開発者は、通常のメモリアクセスパターンに基づいて、平均的なアプリケーションを高速化するために最適化を実装しようとすることが多く、場合によっては「希望どおりにコードを書くことができるはずです。高速でなければなりません。」しかし、そのタイプについて何らかの考えがあった場合、通常、パフォーマンスが重要なフィールドでは失敗します。パフォーマンスが重要な開発者は、コンパイラ、ハードウェア、OS、ドライバなどの複雑な詳細を学び始め、具体的にコードを書き始めるためです。可能な限り最速のコード（キャッシュに適したコードのプリフェッチ、ホット/コールドフィールド分割、SoAsなど）を書くために、それを可能な限り活用するように設計されています。そしてそれは終わらないゲームのようなものです。開発者はパフォーマンスをめぐって競合しているため、パフォーマンスが重要なフィールドでは、これらのものがブラックボックスとして扱われることはありません。

個人的には、仮想メモリが存在しないことを願っています。仮想メモリが存在すると、極端になりすぎて、不測の事態に陥る傾向があり、事態が本当に使い物にならなくなると、パフォーマンスが大幅に低下します。。一部のアプリケーションを使用して、いくつかの入力フィールドに酔ったときに誤って余分な数字を1つまたは2つ入力した場合に、物理メモリがすぐに使い果たされて、OSがクロールされてしまい、 tプログレスバーのキャンセルボタンをクリックすることもできます。Ctrl+ Alt + Delを押してプロセスを終了し、飲み物をこぼして自分に呪いをかけている間、10分間待たなければなりませんでした。 SSDに保存されているページファイルにもかかわらず、そのような場合は、「メモリ不足」エラーか何かを優先したいと思います。この時点で、17個のポルノのタブのいくつかを閉じて（大丈夫です。とにかくお気に入りをブックマークします）、メモリを解放してすぐに実行します。私のビジネスを再開します。