渲染到紋理和同步

我有一個使用標準渲染到紋理設置的跨平臺代碼庫（iOS和Android）。每個幀（初始化之後），按以下順序發生：渲染到紋理和同步

與紋理顏色附件的幀緩衝區的glBindFramebuffer
渲染一些東西
*
glBindFramebuffer默認幀緩衝區（0在Android，通常爲2 iOS上）
那是顏色附着至第一幀緩存
渲染紋理使用結合紋理

在iOS和一些Android設備（包括模擬器）上，這可以正常工作，並且和預期的一樣。在其他設備上（當前坐在運行4.0.4的Samsung Galaxy Note前面），使用該紋理的第二階段渲染看起來很「跳躍」。其他動畫在「跳躍」位相同的屏幕上繼續以60 fps運行;我的結論是，對目標紋理的更改在第二次渲染過程中並不總是可見的。

爲了測試這個理論，我在標有*的步驟中插入了glFinish（）。在所有設備上，現在，這具有正確的行爲。有趣的是，glFlush（）不能解決問題。但是glFinish（）是昂貴的，我還沒有看到任何文件表明這應該是必要的。

所以，這裏是我的問題：當完成渲染到紋理以確保最近繪製的紋理在後續渲染過程中可用時，我該做些什麼？

來源

2013-02-26 addaon

聽起來不像合理的OpenGL行爲。我不是ES專家，但我很確定ES（至少按規範）不會改變這種基本的同步行爲。如果這不起作用，就不能依賴任何東西，就像在渲染之前依靠緩衝區寫入的完成一樣。這些操作沒有其他顯式同步機制，因此命令隊列必須按順序正確同步。 – 2013-02-28 09:20:22

我認爲沒有人觀察到這一點？當然，很可能是設備/構建特定的，但這並不好玩。 – addaon 2013-02-28 18:22:03

你描述的代碼應該沒問題。

只要您使用單個上下文，並且不選擇任何用於放寬同步行爲的擴展（如EXT_map_buffer_range），那麼每個命令都必須看起來像執行完全一樣按照API以及您在從中讀取紋理之前將渲染到紋理中的API用法。

鑑於此，您可能會遇到這些設備上的驅動程序錯誤。你能列出哪些設備遇到問題？您可能會找到常見的硬件或驅動程序。

來源

2013-03-04 03:43:29 Frogblast

渲染到紋理和同步

回答

相關問題