渲染循環 - 最大並行

下面是一個UML序列圖，顯示了我對庫libGDX中游戲循環的理解的處理時間。我認爲它應該是每個其他遊戲庫的相同體系結構。我不確定我是否理解正確。理論上，CPU和GPU並行工作。當CPU等待GPU完成緩衝區更改時，這會使其成爲一個串行進程。如何讓我的遊戲循環並行工作或者我的理解錯誤？渲染循環 - 最大並行

現在我們想要並行化圖像，並且GPU比CPU慢，CPU正在渲染時繼續下一幀。我們有第二個線程等待GPU完成。 GPU完成後，計算下一個圖像。 OpenGL狀態在哪裏改變，繪圖命令現在在哪裏？ GPU現在很忙。這使我得出結論，我錯過了一些東西。

編輯：

羅斯範德建議：

來源

2017-06-18 Benedikt S. Vogler

在第二個圖中，爲什麼渲染調用返回到「CPU線程2」而不是「CPU線程1」？ –

，因爲CPU必須交換前端和後端緩衝區。線程1正在渲染下一幀，所以線程2等待更改緩衝區。 –

對不起，我不清楚你的UML圖試圖通信那麼。圖中的「線程」是「控制線程」還是他們其他的？無論您是否交換兩個指針（或自LibGDX爲java之後的引用），仍然不會更改在GPU上阻塞的控制線程。我錯過了什麼嗎？ –

一個問題，我與第二個圖看看這可能是你要去哪裏錯了就是GPU彷彿回到CPU線程2，即使CPU線程1將數據發送到GPU並開始阻塞它。交換前端和後端緩衝區的兩個引用不會更改哪個線程在GPU上阻塞。我認爲事件的順序應該更像這樣：CPU線程1將數據從前臺緩衝區發送到GPU進行渲染。同時，線程2正在寫入後臺緩衝區。 GPU完成後，線程1可自由交換前後緩衝區（假設線程2完成），然後將數據發送給GPU。線程2在GPU工作時再次寫入後臺緩衝區。

更新：從https://github.com/libgdx/libgdx/wiki/Threading

採取的任何圖形操作直接涉及需要的OpenGL渲染線程上執行。在不同的線程上執行此操作會導致未定義的行爲。這是由於渲染線程上的OpenGL上下文只有有效。使線程在另一個線程上有很多Android設備的問題，因此它不支持。

來源

2017-06-18 12:35:57

這是有道理的，但是這並不能回答我的問題，即在gpu渲染時gl狀態發生變化。他們排隊了嗎？仍然接受你的答案。 –

gl狀態更改只發生在線程1.我將更新我的答案 –

我預計可能會跟進「那麼第二個線程有什麼用處？」。例如，該線程可用於決定繪製遊戲對象的位置。如果你有複雜的遊戲物理或其他CPU密集型計算，可以在第二個線程中完成。然後，一旦你找出了繪製所有東西的位置，你可以從第一個線程開始打開gl調用 –

渲染循環 - 最大並行

回答

相關問題