移動裝置中的CPU和GPU已經變得很強大，到處都是配備一個或多個高解析度螢幕的裝置，需要使用帶有圖形驅動器的複雜互動也日益增加。在這篇部落格文章中，我將討論多執行緒和多視窗渲染對開發人員來講意味著什麼，同時我將介紹將這些技術應用您設計當中的條件和時機。

什麼是多執行緒渲染？
傳統上，OpenGL ES應用程式只從一個執行緒渲染到一個圖層。然而，由於3D渲染引擎的複雜性有所增加，圖形API操作的CPU開銷已經成為瓶頸—尤其是載入資源時。這就使得多執行緒渲染引起關注。

渲染執行緒是與圖形環境關聯的CPU執行緒。預設情況下，每個圖形環境將無法訪問另一個環境中的資源（紋理、著色器和頂點緩衝區）。因此，需要使用共享環境，造成一個或多個後臺負載執行緒可訪問主執行緒的資源。這種渲染模式相當有效的原因有兩個：

1. 主執行緒不會阻塞
從根本上說，一直到應用程式和驅動程式記憶體之間的傳輸完成之前，上傳資料的圖形API呼叫一定會被阻塞。此外，在許多顯示卡驅動程式中著色器編譯就是阻塞型操作。這種阻塞造成開銷較大，導致GPU無法執行。將所有上傳操作遷移至後臺執行緒，主執行緒可以維持統一幀率

在多核CPU上進行並行任務分配
由於圖形驅動程式在CPU上執行，將這項執行分配至多個渲染執行緒，使得作業系統向多個CPU核心並行釋出指令。這就導致與單個渲染執行緒相比，驅動程式的工作負載能夠處理的更為迅速

使用多執行緒渲染？

OpenGL ES資料上傳—未經優化

OpenGL ES資料上傳—經優化

OpenGL ES資料上傳—未經優化

上述簡單示例當中，遊戲當中從一級升至二級需要上傳增加的紋理、 VBO和著色器程式。假設需要完成無縫升級（即啟動畫面、視訊等無法降低上傳開銷） ，仍在渲染一級時遊戲程式必須向驅動程式上傳新資源。

在未經優化的情況下，向驅動程式釋出呼叫指令時，由於增加了上傳/編譯操作負載，每幀所用時間並不一致。提交幀所增加的時間將會造成無法同步重新整理，幀率不一致，會感覺遊戲很卡。

經過優化的情況下，第二執行緒用於上傳資源。這就使得主執行緒維持統一的呼叫遞交時間，保證幀率一致。

最佳實踐
在實現最佳效能時，應在啟動程式時建立渲染執行緒。主執行緒應用於所有渲染。增加的執行緒（在共享環境中建立）應只用於著色器編譯和快取資料上傳。後臺執行緒的數量應保持在最低限度（如每個CPU核心一個執行緒） 。建立執行緒過多會導致難以維護，程式碼無法除錯。

呼叫eglMakeCurrent()應保持在最低限度以降低開銷（EGL specification規定在上下文一定要開啟新執行緒之前，必須重新整理所有未執行的操作）。

什麼情況下不應使用多執行緒渲染？
不受CPU資源限制或不涉及載入次數時
如果執行顯示卡驅動程式時，CPU資源足夠，就應該避免多執行緒渲染。它會增加渲染引擎的複雜性，如果處理得不好，甚至可能降低效能。

試圖“簡化”渲染引擎時
最糟的使用例項是不斷將單一圖形環境繫結至不同執行緒(使用eglmakeCurrent()) 。這樣很糟糕，原因有兩個：
The cost of context binding 上下文開銷
正如以上所述，呼叫eglMakeCurrent()迫使驅動程式取消所有未完成的操作

API calls are serialized API呼叫序列化
由於圖形環境在任何時點只能繫結到一個CPU執行緒，所有API呼叫將被序列提交

因此，API呼叫與單執行緒渲染的開銷一致（API呼叫提交呈序列化），但上行文轉換時需要額外開銷......也就是說與單執行緒渲染相比，效能會較差

似乎這是較好的設計，但以這種方式渲染會導致程式碼複雜凌亂，提交順序不清（甚至更難以除錯！ ） 。
不要這樣做！

這是多視窗渲染？
多視窗渲染將一個應用程式渲染在多個視窗表面。通過作業系統視窗合成器（例如，Android系統的Surface Flinger或Linux發行版的X11）將這些視窗圖層進行合成，以提交至裝置螢幕。

在多視窗應用程式中，CPU執行緒和圖形環境呈一對一對映。每個圖形環境用於渲染到各自的視窗圖層。
什麼時候應該使用多視窗渲染？

多視窗渲染最適合用於應用程式需要渲染一個以上螢幕時，例如，當電視機作為第二屏時。
什麼時候不應該使用多視窗渲染？

合成層

多層合成—未經優化

多層合成—經優化

在上述未經優化的例項中，在單個圖層渲染遊戲場景、觸控控制元件和迷你地圖。應用程式利用作業系統合成器將這些圖層組合成可以顯示的圖層。由於必須要為多個圖層分配記憶體，因此這種方法較浪費資源，該合成器將處理未完全使用的透明畫素和GPU的隱藏面消除（HSR），（即被不透明UI元素覆蓋的片段冗餘著色） 。

在經優化的情況下，遊戲場景第一次渲染，然後觸控控制元件和迷你地圖直接渲染於同一圖層。在應用程式中FBO用於執行合成的情況下，這種方法並不適合。例如，遊戲場景可以被渲染至較低解析度FBO，將點陣圖傳輸至應用程式視窗表面，UI元素可以按原始解析度被驅動至頂點（這項技術通常用於在渲染遊戲場景時增加每個畫素的效能） 。

PVRTrace當中的多執行緒多視窗支援

自IMAGINATION釋出 PowerVR Graphics 3.2 SDK以來 ，PVRTrace（OpenGL ES捕獲和分析工具）支援需要執行這些複雜圖形驅動程式互動的應用程式。其中還包括Call View 和Frame Selector中的每執行緒狀態檢查器、每執行緒過濾，執行緒使用時間軸圖。所有這些功能組合使得多執行緒OpenGL ES更加便於除錯。此外，我們的 PVRVFrameOpenGL ES模擬器的多執行緒支援已經得到顯著改善。

自IMAGINATION釋出 PowerVR Graphics 3.2 SDK以來 ，PVRTrace（OpenGL ES捕獲和分析工具）支援需要執行這些複雜圖形驅動程式互動的應用程式。其中還包括Call View 和Frame Selector中的每執行緒狀態檢查器、每執行緒過濾，執行緒使用時間軸圖。所有這些功能組合使得多執行緒OpenGL ES更加便於除錯。此外，我們的 PVRVFrameOpenGL ES模擬器的多執行緒支援已經得到顯著改善。