昨天參加了公司組織的nvdia的培訓，講了一些關于D3D的優化和可能的瓶頸所在，具體的條目就不說了，這里說一些關于資源的Lock和Unlock，以及我在GL下的測試。

老師講到向Draw*這類函數是將其指令放入指令隊列，帶填滿后或者強制刷新時交給顯卡去畫，也就是說它并不是即時的，而像對資源的Lock和Unlock確是即時的操作，而且cpu和gpu是并行計算的，當lock的資源正是當前gpu正在使用的資源會導致lock堵塞直到gpu使用完后才返回，也就是說不當的使用lock會造成cpu等待gpu的情形。當然D3D的lock函數有一個標記用來告訴lock是否立即返回，使用這個標記后lock會立即返回，并且拿到資源地址，此時cpu如果向該地址寫入新的數據，但gpu也正在使用之，則將出現不可預知的效果。比如lock下一個文理并填入新的數據，此時gpu正使用該紋理進行渲染，則使用該紋理渲染出來東西的紋理將是亂的。

我用OpenGL并且一直使用這么一種方式來管理頂點Buffer和索引Buffer（見下面的描述），但從沒考慮過上面的提到的lock造成的堵塞，當然我用的是OpenGL，但我想Lock這個機制應該是驅動或者顯卡那一級的事情，D3D和GL都應該存Lock的問題。

我這里所謂的管理頂點Buffer和索引Buffer的方式是這樣的?？紤]這么一種情況，當場景中那些粒子也好，動畫也好，比較多的時候，我們要每個都給他們在顯卡上單獨分配頂點緩沖和索引緩沖，畢竟他們的數據是不同的，而且每貞都有變化，即便是使用同一個動畫的角色，在同一時刻也不一定在播放同一貞，這帶來一個問題，當場景中此類對象很多時將占用很多的顯村，且很難控制量，畢竟在引擎這個層面無法知道游戲中到底需要擺放多少個角色，顯卡到底有多少空間可供分配等等。我采用的方式是在引擎啟動之初就再顯卡上分配一個65535個頂點緩沖和65535個索引緩沖，所有需要動態更新頂點Buffer和索引Buffer都填入該緩沖內，并在填充完畢后調用渲染方法。偽代碼如下

for (int indexMesh = 0; indexMesh < 100; indexMesh++)

{

????????????vertex *pv = lock(); // 從共享Buffer中獲得

??????????? {

?????????????????? for (int indexVertex = 0; indexVertex < 1024; indexVertex++)

????????????????? {

???????????????????????????? pv[indexVertex] = position;

??????????????????????????? // ...

????????????????? }

??????????? }

??????????? unlock(pv);

??????????? Render();

}

如果按照之前提到的Lock會被阻塞和數據交叉的問題，那么這么做將會出現效率下降，更嚴重的是會出現數據混亂的問題，或者畫的是最后一次填充的數據。

但是在實際使用和測試中發現這并沒有任何問題，首先說一下效率，lock和unlock只消耗0.025毫秒（當然這個和我提交的數據量關系），渲染幾乎沒有消耗（一共渲染10萬左右個面，顯卡是nv8600gt）。而數據也沒有出現任何混亂。我沒有A卡，沒辦法進行相關測試。

莫非Lock，unLock這個真的是D3D9才有的問題？

總結

以上是生活随笔為你收集整理的渲染优化 lock unlock的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。