並列タスクベースのアーキテクチャを試すために取り組んでいるゲームを中断したくなることがよくありますが、それは私のプロジェクトにとって大きな要件ではないようなので、今のところは避けます。私は、最初におもちゃのプロジェクトで「コンセプトで遊ぶ」ことを試すつもりです。
さて、私が尋ねているのは、多くの（非AAA）ゲームは本当に本当に高いパフォーマンスを必要としないので、タスクベースのエンジンを使用することは気になる価値がないように感じられる...どんな場合ですか？
現時点では、（マルチコア）ハードウェアの最大パフォーマンスを実際に活用する必要がある場合にのみ必要だと思います。タスクベースのエンジンを使用するのが良い他のケースはありますか？それとも、新しいプロジェクトの場合は、タスクベースのエンジンから始めるのが常に良いですか？
回答:
スレッド化は、次の2つの状況で使用されます。
これらのいずれかまたは両方が必要であると合理的に期待できる場合は、それを実行してください。そうでなければ、しないでください。もちろん、あなたが楽しいためにスレッド化するのを止めたり、それをざっと調べて調査したりする人は誰もいませんが、実際にマルチスレッド化されたアプリケーションを取得する利点のためにthreadngを実行することに関しては、上記の2つの使用例は次のとおりです。ほとんどそれ。
ゲームがリモートでハードウェア集約型になる場合は、すべての最新のハードウェアに対応するスレッドが必要です。来年または2年に登場する将来のCPUは、4コアを最小、最大16コアまで、マニア/パフォーマンス市場で一般的になっています。まったくマルチスレッドを実行している場合は、他のスレッドモデルが本質的に将来を見据えたゲームエンジンでは機能しないため、タスク指向のアーキテクチャを確実に実行してください。
ここで、「タスク」とは「ジョブ」を意味し、「異なるエンジンサブシステム用の個別のスレッド」を意味しないことに注意してください。1つのグラフィックススレッド、1つの物理スレッド、1つのAIスレッドなどのようなことは絶対に完全に避けたいと思います。これは、ごく一部のコアを超えてスケーリングすることはなく、実際に実際の並列処理を実現することはできません。物理演算は、AIの更新ごとに複数の更新を実行するべきではありません（AIが物理イベントに反応できるようにする必要があります）。物理演算が実行されていない場合、グラフィックスはほとんど新しくレンダリングされないため、各サブシステムはシーケンスで自然に実行されます注文。あなたは
あなたがしたいのはこれです スレッドスプールを作成します。古典的な一連のサブシステム更新でゲームループを実行します。ただし、サブシステムごとに、ワークロードを個別の分離可能なバッチに分割し、それらをスレッドプールに分散します。ゲーム更新ループの次の状態を実行する前に、すべてのジョブが完了するのを待ちます。一部のサブシステムには複数のサブステージがあります。たとえば、グラフィックは一連のジョブを発行してカリングを実行し、次に2番目の一連のジョブを実行してレンダーキューの作成を実行します。このアプローチは、最初のアプローチの同期の問題を回避し、はるかに多くのコアに拡張でき、率直に言って、コーディング、デバッグ、および保守が簡単になります。
マルチスレッドには2つの用途があります。1つはプログラムのパフォーマンスを向上させることであり、もう1つは進行中の大きなプロセスがあるときにプログラムを実行させることです。たとえば、いくつかのデータをロードしようとしているとき、プログラムがハングアップするのは面倒なので、ロードに別のスレッドを使用してメインスレッドを解放し、メインループを続けることができます。一方、スレッドを使用してパフォーマンスを向上させることは非常に困難です。通常、線形プロセスですべてのことを行うため、並列処理とは対照的です。グラフィカルデバイスの更新には常にメインスレッドを使用する必要があり、スレッド間でタスクを分割することがさらに困難になります。