一千萬個為什麽

搜索

使用多個PBO從opengl前端緩沖區異步回讀

我正在開發一個需要從openGL應用程序的前端緩沖區讀回整個幀的應用程序。我可以劫持應用程序的opengl庫並在swapbuffers上插入我的代碼。目前,我成功地使用了一個簡單但令人難以忍受的慢速glReadPixels命令而沒有PBO。

現在我讀到了使用多個PBO來加快速度。雖然我認為我已經找到足夠的資源來實際編程(並不是那麽難),但我還有一些操作性問題。我會做這樣的事情:

  1. 創建一系列(例如3)PBO的
  2. 在我的swapBuffers覆蓋中使用glReadPixels將數據從前緩沖區讀取到PBO(應該快速且無阻塞,對嗎?)
  3. 創建一個單獨的線程來調用glMapBufferARB,在glReadPixels之後每個PBO調用一次,因為這將阻塞,直到像素在客戶端內存中。
  4. 處理步驟3中的數據。

Now my main concern is of course in steps 2 and 3. I read about glReadPixels used on PBO's being non-blocking, will this be an issue if I issue new opengl commands after that very fast? Will those opengl commands block? Or will they continue (my guess), and if so, I guess only swapbuffers can be a problem, will this one stall or will glReadPixels from front buffer be many times faster than swapping (about each 15->30ms) or, worst case scenario, will swapbuffers be executed while glReadPixels is still reading data to the PBO? My current guess is this logic will do something like this: copy FRONT_BUFFER -> generic place in VRAM, copy VRAM->RAM. But I have no idea which of those 2 is the real bottleneck and more, what the influence on the normal opengl command stream is.

然後在步驟3中。在與普通opengl邏輯分離的線程中異步執行此操作是否明智?目前我認為不是,在執行此操作之後,您似乎必須將緩沖區操作恢復到正常狀態,並且我無法在原始代碼中安裝同步對象以暫時阻止這些操作。所以我認為我最好的選擇是在讀出它們之前定義一個特定的swapbuffer延遲,例如在PBO i%3上調用glReadPixels,在同一線程中調用PBO(i + 2)%3上的glMapBufferARB,導致2幀的延遲。另外,當我調用glMapBufferARB來使用客戶端內存中的數據時,這會成為瓶頸還是glReadPixels(異步)成為瓶頸?

最後,如果你有一些更好的想法來加速opengl中GPU的幀回讀,請告訴我,因為這是我當前系統中的一個痛苦的瓶頸。

我希望我的問題足夠清楚,我知道答案可能也會出現在互聯網上,但我主要想出的結果是使用PBO將緩沖區保存在視頻內存中並在那裏進行處理。我真的需要將前緩沖區讀回RAM並且在這種情況下我沒有找到關於性能的任何明確解釋(我需要,我不能依賴“它更快”,我需要解釋為什麽它更快)。

謝謝

最佳答案

您確定要從前臺緩沖區讀取嗎?您不擁有此緩沖區,並且根據您的操作系統,它可能會被破壞,例如,通過它上面的另一個窗口。

對於您的用例,人們通常會這樣做

  • 畫N
  • 啟動PBO從後臺緩沖區讀取N
  • 畫N + 1
  • 啟動PBO閱讀N + 1
  • 同步PBO讀N
  • 流程N
  • ...

從單個線程。

轉載註明原文: 使用多個PBO從opengl前端緩沖區異步回讀