第四回 關於多執行緒渲染
阿新 • • 發佈：2018-12-27
首先,為什麼呢?為什麼要把渲染部分放到一個單獨的執行緒中去呢?有什麼好處呢?我的理解是這樣的:顯示卡可以看成是一個外設,渲染的過程就是cpu不停的給gpu發各種命令,根據d3d的文件上說,d3d內部有一個command buffer,cpu在呼叫各種d3d的api時,其實是往這個command buffer裡新增命令,這個command buffer是有一定大小的,當這個buffer滿了以後,會有一個flush過程:這個buffer裡的命令會被一齊扔給gpu去執行,然後這個buffer會被清空,以接受新的命令.按照d3d的文件上說,這個flush過程是很慢的,它必須要等待這個command buffer裡的命令全部被gpu執行完,才會返回,不過我自己測了測,似乎不完全是這樣,會有等待,但等待的時間好像並不是全部的執行完這些命令的時間,具體為什麼,我也搞不清楚,也許寫顯示卡驅動的人會更瞭解一些吧,d3d對我們這些寫應用程式的人來說就是黑盒子.不過阻塞是一定會有的.所以我認為可以把gpu連同D3D看成一個類似硬碟的io裝置.cpu通過呼叫d3d的api來給這個裝置發命令,大多數情況下,這些api立即就返回了(這些命令被cache在d3d內部的一個command buffer裡),但是偶爾的,當一個api呼叫試圖在一個已經滿了的command buffer裡再加入命令時,就會觸發一次d3d內部的flush過程,而這個時候,這個api呼叫就必須等待這個io裝置了,也就是cpu這個時候是空閒的,計算能力在這裡被浪費了.很多關於d3d的教材都提到不要呼叫太多的draw call,應該把多個draw call合併在同一個batch裡,我以前以為,可能是因為d3d api的呼叫本身有開銷,我現在的理解是,draw call太多,會導致太多的d3d api呼叫,太多的命令,而這樣會導致d3d內部的command buffer頻繁溢位,從而導致d3d內部頻繁的flush,加劇了cpu等待gpu的情況. 如果d3d的內部運作模式真是我上面描述的那樣的話,把渲染部分放到一個單獨的執行緒中去就顯得有必要了,因為可以把cpu在等待gpu的時間充分利用起來,或者至少不會讓這些等待耽誤到主執行緒的執行.