簡體 English 中英

GPU 與 OpenGL、GLSL 和幀緩沖對象的圖像處理 - 關於性能的問題

[英]Image processing on the GPU with OpenGL, GLSL and Framebuffer Objects - questions about performance

原文 2011-05-31 11:41:24 8 1 performance/ opengl/ image-processing/ glsl/ gpu

我參與了一個項目，該項目在 CPU 上進行圖像處理，目前正在擴展以使用GPU ，希望主要使用 GPU，如果證明更快，並且 CPU 處理部分為一個后備。 我是 GPU 編程的新手，並且有一些問題，我在其他線程中已經討論過這些問題，但無法找到我需要的答案。

如果我們從頭開始，您會推薦什么技術在 GPU 上進行圖像處理，以實現覆蓋范圍（如客戶端機器上的支持）和速度的最佳組合？ 我們已經采用OpenGL + GLSL方式作為覆蓋盡可能多的顯卡的方式，我很好奇這是否是最佳選擇。 例如，您對OpenCL有什么看法？
鑒於我們已經開始使用 OpenGL 和着色器來實現 GPU 模塊，我想知道我們這樣做是否是最有效的方式。
我們使用Framebuffer Objects來讀取和渲染紋理。 在大多數情況下，正在讀取的區域和正在寫入的區域大小相同，但我們讀取和寫入的紋理可以是任意大小。 換句話說，我們要求 FBO 讀取被認為是其輸入紋理的子區域，並寫入被認為是其 output 紋理的子區域。 為此，output 紋理“附加”到幀緩沖區 Object（使用glFramebufferTexture2DEXT ()），但輸入的不是。 這要求紋理被“附加”和“分離”，因為它們改變了它們的角色（即紋理最初可以用於寫入，但在下一次傳遞中，它可以用作讀取的輸入）。
相反，強制輸入和輸出大小相同並始終將它們附加到 FBO 是否更有意義，就有效地使用 FBO 並獲得更好的性能而言，還是我們已經做的聽起來足夠好？
該項目最初設計為在 CPU 上渲染，因此需要注意一次渲染盡可能少的像素的請求。 因此，每當發生鼠標移動時，例如，只有 cursor 周圍的一個非常小的區域會被重新渲染。 或者，在渲染覆蓋屏幕的整個圖像時，它可能會被分割成條帶，一個接一個地渲染和顯示。 在 GPU 上渲染時，這種碎片是否有意義？ 確定渲染請求的最佳大小（即 output 紋理）的最佳方法是什么，以便充分利用 GPU？
在分析在 GPU 上運行的代碼（出於性能考慮）時會有哪些注意事項？ （將其與 CPU 上的渲染進行比較。）測量調用返回所需的時間（並調用 glFinish() 以確保命令已在 GPU 上完成）聽起來有用還是有其他要記住的？

非常感謝！

我想我需要添加一些細節來澄清我的問題：

2）我們實際上並沒有同時使用相同的紋理作為渲染目標和讀取源。 只有在渲染完成后，“輸出”紋理才會變為“輸入”——即，當需要讀取渲染作業的結果以進行另一次傳遞或作為另一個過濾器的輸入時。

我關心的是附加的紋理是否被不同地處理，例如 FBO 或着色器是否可以更快地訪問它們，與未附加時相比。

我最初的（雖然可能不完全准確）的分析沒有顯示出巨大的差異，所以我想我們並沒有犯下那么多的性能犯罪。 我會用你建議的計時功能做更多的測試——這些看起來很有用。

3）我想知道將圖片切成小塊（比如鼠標移動小至 100 x 100 像素）並要求它們逐個渲染會更慢或更快（或者是否無關緊要）一個 GPU，它可能會並行化很多工作。我的直覺是，這可能是過分熱心的優化，在最好的情況下，不會給我們帶來太多收益，在最壞的情況下，可能會損害性能，所以想知道是否有一種正式的方式來說明特定的實現。 最后，我想我們會使用 go 與各種顯卡的合理配置。

1 個解決方案

我對您的項目沒有太多的了解，但我會嘗試提供一些簡單的答案，也許其他人可以更詳細：

只要您在沒有太多同步的情況下從圖像處理中執行通常的 modify-output-pixels-using-some-input-pixels 任務，您應該可以使用通常的屏幕尺寸四邊形與片段着色器方法（對不起這些奇怪的短語）。 而且您可以免費獲得圖像過濾（如雙線性插值）（我不知道 CUDA 或 OpenCL 是否支持圖像過濾，盡管它們應該支持，因為硬件仍然存在）。
無論如何，您都無法從用作渲染目標的紋理中讀取數據（盡管我認為它們可能仍會附加），因此您當前的方法應該沒問題。 要求它們大小相同只是為了讓它們連接到 FBO 會極大地限制靈活性（我認為連接成本可以忽略不計）。
最佳尺寸實際上取決於實現，但限制渲染范圍，因此片段着色器調用應該始終是一個好主意，只要這些限制計算不會持續太久（我認為使用glScissor的簡單邊界框是你的朋友，或僅使用小於屏幕尺寸的四邊形）。
還有其他可能更准確的方法來計時 GPU（例如，查看GL_ARB_timer_query擴展）。 對於分析和調試，您可以使用通用 GPU 分析器和調試器，如 gDEBugger 等，我認為。 雖然我對這些工具沒有太多經驗。

編輯：對您編輯的問題：

我真的懷疑，附加紋理的讀取速度是否比非附加紋理快。 您唯一可以獲得的是，當您想寫入它時，您不需要重新附加它，但正如我所說，如果有的話，這個成本應該可以忽略不計。
我不會通過將其平鋪成太小的部分來過度優化它。 就像我說的，在使用 GL 時，您可以使用剪刀測試和模板測試來處理這些事情。 但我認為，這一切都必須經過測試，以確保性能提升。 我不知道，您的鼠標移動是什么意思，因為當您將鼠標移到 window 上時，window 系統通常負責渲染 cursor，因為它不需要重新繪制底層圖像，所以您需要再次繪制底層圖像我認為由 window 系統緩沖。