ゲームループとopenGLの間のマルチスレッドを利用する

openGLレンダラーに基づくゲームのコンテキストで話す：

2つのスレッドがあるとしましょう：

1. ゲーム内オブジェクトのゲームロジックや物理などを更新します

2. ゲームオブジェクトのデータ（スレッド1が更新し続ける）に基づいて、各ゲームオブジェクトのopenGL描画呼び出しを行います。

ゲームの現在の状態で各ゲームオブジェクトの2つのコピーがない限り、スレッド2が描画呼び出しを行っている間、スレッド1を一時停止する必要があります。そうでない場合、ゲームオブジェクトはそのオブジェクトの描画呼び出しの途中で更新されます。望ましくない！

ただし、スレッド1を停止してスレッド2から安全に描画呼び出しを行うと、マルチスレッド/同時実行の目的全体が失われます。

マルチコアアーキテクチャを活用してパフォーマンスを向上させるために、数百または数千または同期オブジェクト/フェンスを使用する以外に、これに対するより良いアプローチはありますか？

マルチスレッドを使用して、現在のゲームの状態にまだ含まれていないオブジェクトのテクスチャをロードしてシェーダーをコンパイルできることはわかっていますが、アクティブ/可視オブジェクトに対して、描画と更新の競合を引き起こさずにそれを行うにはどうすればよいですか？

ゲームオブジェクトごとに個別の同期ロックを使用するとどうなりますか？このように、すべてのスレッドは、更新/描画サイクル全体ではなく、1つのオブジェクト（理想的なケース）でのみブロックします！しかし、各オブジェクトのロックを取得するのにどのくらいのコストがかかりますか（ゲームには1000のオブジェクトがある場合があります）？

これまでに説明したロックを使用したアプローチは、非常に非効率的であり、単一のスレッドを使用する場合よりも遅くなる可能性があります。各スレッドでデータのコピーを保持する他のアプローチは、おそらく「速度の点で」うまく機能しますが、コピーを同期させるには、法外なメモリコストとコードの複雑さがあります。

これにはいくつかの代替アプローチがあります。マルチスレッドレンダリングの一般的な解決策の1つは、コマンドのダブルバッファを使用することです。これは、レンダラーバックエンドを別のスレッドで実行することで構成され、すべての描画呼び出しとレンダリングAPIとの通信が実行されます。ゲームロジックを実行するフロントエンドスレッドは、コマンドバッファー（ダブルバッファー）を介してバックエンドレンダラーと通信します。。この設定では、フレームの完了時に同期点が1つだけあります。フロントエンドがレンダーコマンドで1つのバッファを埋めている間、バックエンドはもう1つを消費しています。両方のスレッドのバランスが取れていると、枯渇することはありません。このアプローチは最適ではありませんが、レンダリングされたフレームにレイテンシが導入されるため、OpenGLドライバーは独自のプロセスで既にこれを行っている可能性が高いため、パフォーマンスの向上を慎重に測定する必要があります。また、せいぜい2つのコアしか使用しません。このアプローチは、Doom 3やQuake 3などの成功したゲームでも使用されています。

マルチコアCPUをより有効に活用する、よりスケーラブルなアプローチは、独立したタスクに基づくもので、セカンダリスレッドで処理される非同期リクエストを起動し、リクエストを起動したスレッドは他の作業を続行します。ロックを回避するために、タスクは他のスレッドとの依存関係がないことが理想的です（ペストのような共有/グローバルデータも避けてください！）。タスクベースのアーキテクチャは、アニメーションの計算、AIパスファインディング、手続き型の生成、シーンプロップの動的ロードなど、ゲームのローカライズされた部分でより使いやすくなっています。ゲームは自然にイベントフルであり、ほとんどの種類のイベントは非同期であるため、別のスレッドで実行するのは簡単です。

最後に、私は読むことをお勧めします：

• インテルによるゲームのスレッディングの基本。

• ハーブサッターによる効果的な同時実行性（このページの他の優れたリソースへのリンクがいくつかあります）。