2017-06-18 10 views
0

以下は、ライブラリlibGDXのゲームループを理解したときの処理時間を示すUMLシーケンス図です。他のすべてのゲームライブラリと同じアーキテクチャでなければならないと思います。私が正しく理解しているかどうかはわかりません。 sequence diagram CP and GPU serial 理論的には、CPUとGPUは並行して動作します。 CPUがバッファ変更のためにGPUが終了するまでCPUが待機すると、これはシリアル・プロセスになります。 ゲームループを並行して動作させるにはどうすればよいですか、それとも私の理解が間違っていますか?レンダリングループ - 最大並列化

これで、GPUがCPUよりも遅くなり、GPUがレンダリングされている間にCPUが次のフレームで処理を続行するようにしました。 GPUが終了するのを待っている2番目のスレッドがあります。 GPUが完了すると、次の画像が計算されます。 OpenGLの状態が変わり、描画コマンドはどこに行きますか? GPUは現在忙しいです。これは、私が何かを欠いているという結論につながります。 sequence diagram parallel Cpu and GPU

EDIT:ロス・ヴァンダーによって推奨

:私はあなたが間違っているところであってもよい第2の図で見る suggested by Vander

+0

2番目の図で、レンダリング呼び出しが「CPUスレッド1」ではなく「CPUスレッド2」に戻るのはなぜですか? –

+0

CPUがフロントバッファとバックバッファをスワップする必要があるためです。スレッド1が次のフレームをレンダリングしているので、スレッド2はバッファを変更するのを待ちます。 –

+1

申し訳ありませんが、UML図が何を伝えようとしているのかはわかりません。ダイアグラム内の「スレッド」は「制御スレッド」ですか、それとも別のスレッドですか? 2つのポインタ(またはLibGDXがJavaであるので参照)を入れ替えても、GPUでブロックされたコントロールのスレッドは変更されません。何か不足していますか? –

答えて

1

一つの問題は、GPUがCPUスレッドに戻っているようだということです2 GPUにデータを送信してCPUスレッド1のブロックを開始したのはCPUスレッド1であったにもかかわらず、フロントバッファとバックバッファの2つの参照を入れ替えても、どのスレッドがGPUでブロックしているかは変わりません。 私はイベントの順序はこれより似ているべきだと思います:CPUスレッド1は、フロントバッファからGPUにデータを送信してレンダリングします。同時に、スレッド2はバックバッファに書き込んでいます。 GPUが終了すると、スレッド1はフロントバッファとバックバッファを自由に交換し(スレッド2が完了したと仮定して)、GPUにデータを送信します。スレッド2は、GPUが動作している間にバックバッファに再度書き込みます。

更新:任意のグラフィックス操作は、直接OpenGLはレンダリングスレッド上で を実行する必要が関与https://github.com/libgdx/libgdx/wiki/Threading

から取られました。別のスレッドでこれを行うと、結果は未定義の になります。これは、レンダリングスレッドでOpenGLコンテキストが のみアクティブであるためです。別の スレッドのコンテキストを最新のものにすることは、多くのAndroidデバイスで問題を抱えているため、 がサポートされていません。

+0

これは理にかなっていますが、これはgpuがレンダリングされているときgl状態の変更がどこにあるのかという私の質問には答えません。彼らは待ち行列に入れられていますか?まだあなたの答えを受け入れました。 –

+0

gl状態の変更はスレッド1でのみ発生します。私の回答は –

+0

に更新されます。「2番目のスレッドはどのような用途ですか?」のフォローアップが予想されます。そのスレッドは、例えば、あなたのゲームオブジェクトをどこに描画するかを決めるために使用できます。あなたが複雑なゲームフィジックスや他のCPU集約的な計算をしている場合、それらは第2のスレッドで行うことができます。そして、一度すべてを描く場所を見つけたら、最初のスレッドからopen gl呼び出しを行うことができます –

関連する問題