“內容歸納” 應用程式和驅動程式之間的傳輸完成之前，阻塞型操作有： 1、上傳資料的圖形API呼叫； 2、顯示卡驅動程式中著色器編譯；

一、什麼情況下使用：

多執行緒渲染最適合於編譯著色器或上傳資料至顯示卡驅動器時CPU資源有限的應用程式。原因有2:

• 主執行緒不會阻塞 從根本上說，一直到應用程式和驅動程式記憶體之間的傳輸完成之前，上傳資料的圖形API呼叫一定會被阻塞。此外，在許多顯示卡驅動程式中著色器編譯就是阻塞型操作。這種阻塞造成開銷較大，導致GPU無法執行。將所有上傳操作遷移至後臺執行緒，主執行緒可以維持統一幀率
• 在多核CPU上進行並行任務分配 由於圖形驅動程式在CPU上執行，將這項執行分配至多個渲染執行緒，使得作業系統向多個CPU核心並行釋出指令。這就導致與單個渲染執行緒相比，驅動程式的工作負載能夠處理的更為迅速

二、什麼情況不使用：

1、不受CPU資源限制或不涉及載入次數時，執行顯示卡驅動程式時，CPU資源足夠。 2、檢視“簡化”渲染引擎時： 最糟的使用例項是不斷將單一圖形環境繫結至不同執行緒(使用eglmakeCurrent()) ，原因有2：

• The cost of context binding 上下文開銷 呼叫eglMakeCurrent()迫使驅動程式取消所有未完成的操作，應保持在最低限度以降低開銷。
• API calls are serialized API呼叫序列化 由於圖形環境在任何時點只能繫結到一個CPU執行緒，所有API呼叫將被序列提交

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

知識點：

1、共享環境（共享context），一個或多個後臺負載執行緒可訪問主執行緒的資源。 2、後臺執行緒的數量應保持在最低限度（如每個CPU核心一個執行緒） 。