深入理解D3D9對(duì)圖形程序員來(lái)說(shuō)意義重大，我把以前的一些學(xué)習(xí)筆記都匯總起來(lái)，希望對(duì)朋友們有些所幫助，因?yàn)槭橇闵⒐P記，思路很雜，還請(qǐng)包涵。

其實(shí)只要你能完美理解D3DLOCK、D3DUSAGE、D3DPOOL、LOST DEVICE、QUERY、Present（）、BeginScene（）、EndScene（）等概念，就算是理解D3D9了， 不知道大家有沒(méi)有同感。有如下幾個(gè)問(wèn)題，如果你能圓滿回答就算過(guò)關(guān)：）。
1、       D3DPOOL_DEFAULT、D3DPOOL_MANAGED、D3DPOOL_SYSTEMMEM和D3DPOOL_SCRATCH到底有何本質(zhì)區(qū)別？
2、       D3DUSAGE的具體怎么使用？
3、       什么是Adapter？什么是D3D Device？HAL Device和Ref Device有何區(qū)別？Device的類型又和Vertex Processing類型有什么關(guān)系？
4、       APP（CPU）、RUNTIME、DRIVER、GPU是如何協(xié)同工作的？D3D API是同步函數(shù)還是異步函數(shù)？
5、       Lost Device到底發(fā)生了什么？為什么在設(shè)備丟失后D3DPOOL_DEFAULT類型資源需要重新創(chuàng)建？

在D3D中有三大對(duì)象，他們是D3D OBJECT、D3D ADAPTER和D3D DEVICE。D3D OBJECT很簡(jiǎn)單，就是一個(gè)使用D3D功能的COM對(duì)象，其提供了創(chuàng)建DEVICE和枚舉ADAPTER的功能。ADAPTER是對(duì)計(jì)算機(jī)圖形硬件和軟件性能的一個(gè)抽象，其包含了DEVICE。DEVICE則是D3D的核心，它包裝了整個(gè)圖形流水管線，包括變換、光照和光柵化（著色），根據(jù)D3D版本不同，流水線也有區(qū)別，比如最新的D3D10就包含了新的GS幾何處理。圖形管線的所有功能由DRIVER提供，而DIRVER分兩類，一種是GPU硬件DRIVER，另一種是軟件DRIVER，這就是為什么在D3D中主要有兩類DEVICE， REF和HAL，使用REF DEVICE時(shí)，圖形管線的光柵化功能由軟件DRIVER在CPU上模擬的，REF DEVICE從名字就可以看出這個(gè)給硬件廠商做功能參考用的，所以按常理它應(yīng)該是全軟件實(shí)現(xiàn)，具備全部DX標(biāo)準(zhǔn)功能。而使用HAL DEVICE時(shí)，RUNTIME則將使用HAL硬件層控制GPU來(lái)完成變換、光照和光柵化，而且只有HAL DEVICE中同時(shí)實(shí)現(xiàn)了硬件頂點(diǎn)處理和軟件頂點(diǎn)處理（REF DEVICE一般不能使用硬件頂點(diǎn)處理，除非自己在驅(qū)動(dòng)上做手腳，比如PERFHUD）。另外還有個(gè)一個(gè)不常用的SOFTWARE DEVICE，用戶可以使用DDI編寫(xiě)自己的軟件圖形驅(qū)動(dòng)，然后注冊(cè)進(jìn)系統(tǒng)，之后便可在程序中使用。

檢查系統(tǒng)軟件硬件性能。
在程序的開(kāi)始我們就要判斷目標(biāo)機(jī)的性能，其主要流程是：
確定要用的緩沖格式
GetAdapterCount()
GetAdapterDisplayMode

GetAdapterIdentifier //得到適配器描述
CheckDeviceType //判斷指定適配器上的設(shè)備是否支持硬件加速
GetDeviceCaps //指定設(shè)備的性能，主要判斷是否支持硬件頂點(diǎn)處理(T&L)
GetAdapterModeCount //得到適配器上指定緩沖格式所有可用的顯示模式
EnumAdapterModes //枚舉所有顯示模式
CheckDeviceFormat
CheckDeviceMultiSampleType
詳細(xì)使用請(qǐng)參考DX文檔。

WINDOWS圖形系統(tǒng)的主要分為四層：圖形應(yīng)用程序、D3D RUNTIME、SOFTWARE DRIVER和GPU。此四層是按功能來(lái)分的，實(shí)際上他們之間界限并不如此明確，比如RUNTIME中其實(shí)也包含有USER MODE的SOFTWARE DRIVER，詳細(xì)結(jié)構(gòu)這里不再多說(shuō)。而在RUNTIME里有一個(gè)很重要的結(jié)構(gòu)，叫做command buffer，當(dāng)應(yīng)用程序調(diào)用一個(gè)D3D API時(shí)，RUNTIME將調(diào)用轉(zhuǎn)換成設(shè)備無(wú)關(guān)的命令，然后將命令緩沖到這個(gè)COMMAND BUFFER中，這個(gè)BUFFER的大小是根據(jù)任務(wù)負(fù)載動(dòng)態(tài)改變的，當(dāng)這個(gè)BUFFER滿員之后，RUNTIME會(huì)讓所有命令FLUSH到KERNEL模式下的驅(qū)動(dòng)中，而驅(qū)動(dòng)中也是有一個(gè)BUFFER的，用來(lái)存儲(chǔ)已被轉(zhuǎn)換成的硬件相關(guān)的命令，D3D一般只允許其緩沖最多3個(gè)幀的圖形指令，而且RUNTIME和DRIVER都會(huì)被BUFFER中的命令做適當(dāng)優(yōu)化，比如我們?cè)诔绦蛑羞B續(xù)設(shè)置同一個(gè)RENDER STATE，我們就會(huì)在調(diào)試信息中看到如下信息“Ignoring redundant SetRenderState - X”，這便是RUNTIME自動(dòng)丟棄無(wú)用的狀態(tài)設(shè)置命令。在D3D9中可以使用QUERY機(jī)制來(lái)與GPU進(jìn)行異步工作，所謂QUERY就是查詢命令，用來(lái)查詢RUNTIME、DRIVER或者GPU的狀態(tài)，D3D9中的QUERY對(duì)象有三種狀態(tài)，SIGNALED、BUILDING和ISSUED，當(dāng)他們處于空閑狀態(tài)后會(huì)將查詢狀態(tài)置于SIGNALED STATE，查詢分開(kāi)始和結(jié)束，查詢開(kāi)始表示對(duì)象開(kāi)始記錄應(yīng)用程序所需數(shù)據(jù)，當(dāng)應(yīng)用程序指定查詢結(jié)束后，如果被查詢的對(duì)象處于空閑狀態(tài)，則被查詢對(duì)象會(huì)將查詢對(duì)象置于SIGNALED狀態(tài)。GetData則是用來(lái)取得查詢結(jié)果，如果返回的是D3D_OK則結(jié)果可用，如果使用D3DGETDATA_FLUSH標(biāo)志，表示將COMMAND BUFFER中的所有命令都發(fā)送到DRIVER。現(xiàn)在我們知道D3D API絕大部分都是同步函數(shù)，應(yīng)用程序調(diào)用后，RUNTIME只是簡(jiǎn)單的將其加入到COMMAND BUFFER，可能有人會(huì)疑惑我們?nèi)绾螠y(cè)定幀率？又如何分析GPU時(shí)間呢？對(duì)于第一個(gè)問(wèn)題我們要看當(dāng)一幀完畢，也就是PRESENT()函數(shù)調(diào)用是否被阻塞，答案是可能被阻塞也可能不被阻塞，要看RUNTIME允許緩沖中存在的指令數(shù)量，如果超過(guò)額度，則PRESENT函數(shù)會(huì)被阻塞下來(lái)，如何PRESENT完全不被阻塞，當(dāng)GPU執(zhí)行繁重的繪制任務(wù)時(shí)，CPU工作進(jìn)度會(huì)大大超過(guò)GPU，導(dǎo)致游戲邏輯快于圖形顯示，這顯然是不行的。測(cè)定GPU工作時(shí)間是件很麻煩的事，首先我們要解決同步問(wèn)題，要測(cè)量GPU時(shí)間，首先我們必須讓CPU與GPU異步工作，在D3D9中可以使用QUERY機(jī)制做到這點(diǎn)，讓我們看看Accurately Profiling Driect3D API Calls中的例子:
IDirect3DQuery9* pQueryEvent;

//1.創(chuàng)建事件類型的查詢事件
m_pD3DDevice->CreateQuery( D3DQUERYTYPE_EVENT, &pQueryEvent);
//2.在COMMAND BUFFER中加入一個(gè)查詢結(jié)束的標(biāo)記，此查詢默認(rèn)開(kāi)始于CreateDevice
pQueryEvent->Issue(D3DISSUE_END);
//3.將COMMAND BUFFER中的所有命令清空到DRIVER中去，并循環(huán)查詢事件對(duì)象轉(zhuǎn)換到SIGNALED狀態(tài)，當(dāng)GPU完成CB中所有命令后會(huì)將查詢事件狀態(tài)進(jìn)行轉(zhuǎn)換。
while(S_FALSE == pQueryEvent->GetData( NULL, 0, D3DGETDATA_FLUSH) )
     ;
LARGE_INTEGER start, stop;
QueryPerformanceCounter(&start); 
SetTexture();
DrawPrimitive(); 
pQueryEvent->Issue(D3DISSUE_END);
while(S_FALSE == pQueryEvent->GetData( NULL, 0, D3DGETDATA_FLUSH) )
       ;
QueryPerformanceCounter(&stop); 

1.第一個(gè)GetData調(diào)用使用了D3DGETDATA_FLUSH標(biāo)志，表示要將COMMAND BUFFER中的繪制命令都清空到DRIVER中去，當(dāng)GPU處理完所有命令后會(huì)將這個(gè)查詢對(duì)象狀態(tài)置SIGNALED。
2.將設(shè)備無(wú)關(guān)的SETTEXTURE命令加入到RUNTIME的COMMAND BUFFER中。
3.將設(shè)備無(wú)關(guān)的DrawPrimitive命令加入到RUNTIME的COMMAND BUFFER中。
4.將設(shè)備無(wú)關(guān)的ISSUE命令加入到RUNTIME的COMMAND BUFFER中。
5.GetData會(huì)將BUFFER中的所有命令清空到DRIVER中去，注意這是GETDATA不會(huì)等待GPU完成所有命令的執(zhí)行才返回。這里會(huì)有一個(gè)從用戶模式到核心模式的切換。
6.等待DRIVER將所有命令都轉(zhuǎn)換為硬件相關(guān)指令，并填充到DRIVER BUFFER中后，調(diào)用從核心模式返回到用戶模式。
7.GetData循環(huán)查詢 查詢對(duì)象 狀態(tài)。當(dāng)GPU完成所有DRIVER BUFFER中的指令后會(huì)改變查詢對(duì)象的狀態(tài)。

如下情況可能清空RUNTIME COMMAND BUFFER，并引起一個(gè)模式切換：
1.Lock method（某些條件下和某些LOCK標(biāo)志）

2.創(chuàng)建設(shè)備、頂點(diǎn)緩沖、索引緩沖和紋理
3.完全釋放設(shè)備、頂點(diǎn)緩沖、索引緩沖和紋理資源
4.調(diào)用ValidateDevice
5.調(diào)用Present
6.COMMAND BUFFER已滿
7.用D3DGETDATA_FLUSH調(diào)用GetData函數(shù)

對(duì)于D3DQUERYTYPE_EVENT的解釋我不能完全理解（Query for any and all asynchronous events that have been issued from API calls）明白的朋友一定告訴我，只知道當(dāng)GPU處理完D3DQUERYTYPE_EVENT類型查詢?cè)?span lang=EN-US style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px">CB中加入的D3DISSUE_END標(biāo)記后，會(huì)將查詢對(duì)象狀態(tài)置SIGNALED狀態(tài)，所以CPU等待查詢一定是異步的。為了效率所以盡量少在PRESENT之前使用BEGINSCENE ENDSCENE對(duì)，為什么會(huì)影響效率？原因只能猜測(cè)，可能EndScene會(huì)引發(fā)Command buffer flush這樣會(huì)有一個(gè)執(zhí)行的模式切換，也可能會(huì)引發(fā)D3D RUNTIME對(duì)MANAGED資源的一些操作。而且ENDSCENE不是一個(gè)同步方法，它不會(huì)等待DRIVER把所有命令執(zhí)行完才返回。 

D3D RUTIME的內(nèi)存類型，分為3種，VIDEO MEMORY（VM）、AGP MEMORY（AM）和SYSTEM MEMORY（SM），所有D3D資源都創(chuàng)建在這3種內(nèi)存之中，在創(chuàng)建資源時(shí)，我們可以指定如下存儲(chǔ)標(biāo)志，D3DPOOL_DEFAULT、D3DPOOL_MANAGED、D3DPOOL_SYSTEMMEM和D3DPOOL_SCRATCH。VM就是位于顯卡上的顯存，CPU只能通過(guò)AGP或PCI-E總線訪問(wèn)到，讀寫(xiě)速度都是非常慢的，CPU連續(xù)寫(xiě)VM稍微快于讀，因?yàn)?span lang=EN-US style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px">CPU寫(xiě)VM時(shí)會(huì)在CACHE中分配32或64個(gè)字節(jié)（取決于CACHE LINE長(zhǎng)度）的寫(xiě)緩沖，當(dāng)緩沖滿后會(huì)一次性寫(xiě)入VM；SM就是系統(tǒng)內(nèi)存，CPU讀寫(xiě)都非常快，因?yàn)?span lang=EN-US style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px">SM是被CACHE到2級(jí)緩沖的，但GPU卻不能直接訪問(wèn)到系統(tǒng)緩沖，所以創(chuàng)建在SM中的資源，GPU是不能直接使用的；AM是最麻煩的一個(gè)類型，AM實(shí)際也存在于系統(tǒng)內(nèi)存中，但這部分MEM不會(huì)被CPU CACHE，意味著CPU讀寫(xiě)AM都會(huì)寫(xiě)來(lái)個(gè)CACHE MISSING然后才通過(guò)內(nèi)存總線訪問(wèn)AM，所以CPU讀寫(xiě)AM相比SM會(huì)比較慢，但連續(xù)的寫(xiě)會(huì)稍微快于讀，原因就是CPU寫(xiě)AM使用了“write combining”，而且GPU可以直接通過(guò)AGP或PCI-E總線訪問(wèn)AM。 

如果我們使用D3DPOOL_DEFAULT來(lái)創(chuàng)建資源，則表示讓D3D RUNTIME根據(jù)我們指定的資源使用方法來(lái)自動(dòng)使用存儲(chǔ)類型，一般是VM或AM，系統(tǒng)不會(huì)在其他地方進(jìn)行額外備份，當(dāng)設(shè)備丟失后，這些資源內(nèi)容也會(huì)被丟失掉。但系統(tǒng)并不會(huì)在創(chuàng)建的時(shí)候使用D3DPOOL_SYSTEMMEM或D3DPOOL_MANAGED來(lái)替換它，注意他們是完全不同的POOL類型，創(chuàng)建到D3DPOOL_DEFAULT中的紋理是不能被CPU LOCK的，除非是動(dòng)態(tài)紋理。但創(chuàng)建在D3DPOOL_DEFAULT中的VB IB RENDERTARGET BACK BUFFERS可以被LOCK。當(dāng)你用D3DPOOL_DEFAULT創(chuàng)建資源時(shí)，如果顯存已經(jīng)使用完畢，則托管資源會(huì)被換出顯存來(lái)釋放足夠的空間。 D3DPOOL_SYSTEMMEM和D3DPOOL_SCRATCH都是位于SM中的，其差別是使用D3DPOOL_SYSTEMMEM時(shí)，資源格式受限于Device性能，因?yàn)橘Y源很可能會(huì)被更新到AM或VM中去供圖形系統(tǒng)使用，但SCRATCH只受RUNTIME限制，所以這種資源無(wú)法被圖形系統(tǒng)使用。 D3DRUNTIME會(huì)優(yōu)化D3DUSAGE_DYNAMIC 資源，一般將其放置于AM中，但不敢完全保證。另外為什么靜態(tài)紋理不能被LOCK，動(dòng)態(tài)紋理卻可以，都關(guān)系到D3D RUNTIME的設(shè)計(jì)，在后面D3DLOCK說(shuō)明中會(huì)敘述。

D3DPOOL_MANAGED表示讓D3D RUNTIME來(lái)管理資源，被創(chuàng)建的資源會(huì)有2份拷貝，一份在SM中，一份在VM/AM中，創(chuàng)建的時(shí)候被放置L在SM，在GPU需要使用資源時(shí)D3D RUNTIME自動(dòng)將數(shù)據(jù)拷貝到VM中去，當(dāng)資源被GPU修改后，RUNTIME在必要時(shí)自動(dòng)將其更新到SM中來(lái)，而在SM中修改后也會(huì)被UPDATE到VM去中。所以被CPU或者GPU頻發(fā)修改的數(shù)據(jù)，一定不要使用托管類型，這樣會(huì)產(chǎn)生非常昂貴的同步負(fù)擔(dān)。當(dāng)LOST DEVICE發(fā)生后，RESET時(shí)RUNTIME會(huì)自動(dòng)利用SM中的COPY來(lái)恢復(fù)VM中的數(shù)據(jù)，因?yàn)閭浞菰?span lang=EN-US style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px">SM中的數(shù)據(jù)并不是全部都會(huì)提交到VM中，所以實(shí)際備份數(shù)據(jù)可以遠(yuǎn)多于VM容量，隨著資源的不斷增多，備份數(shù)據(jù)很可能被交換到硬盤(pán)上，這是RESET的過(guò)程可能變得異常緩慢，RUNTIME給每個(gè)MANAGED資源都保留了一個(gè)時(shí)間戳，當(dāng)RUNTIME需要把備份數(shù)據(jù)拷貝到VM中時(shí)，RUNTIME會(huì)在VM中分配顯存空間，如果分配失敗，表示VM已經(jīng)沒(méi)有可用空間，這樣RUNTIME會(huì)使用LRU算法根據(jù)時(shí)間戳釋放相關(guān)資源，SetPriority通過(guò)時(shí)間戳來(lái)設(shè)置資源的優(yōu)先級(jí)，最近常用的資源將擁有高的優(yōu)先級(jí)，這樣RUNTIME通過(guò)優(yōu)先級(jí)就能合理的釋放資源，發(fā)生釋放后馬上又要使用這種情況的幾率會(huì)比較小，應(yīng)用程序還可以調(diào)用EvictManagedResources強(qiáng)制清空VM中的所有MANAGED資源，這樣如果下一幀有用到MANAGED資源，RUNTIME需要重新載入，這樣對(duì)性能有很大影響，平時(shí)一般不要使用，但在關(guān)卡轉(zhuǎn)換的時(shí)候，這個(gè)函數(shù)是非常有用的，可以消除VM中的內(nèi)存碎片。LRU算法在某些情況下有性能缺陷，比如繪制一幀所需資源量無(wú)法被VM裝下的時(shí)候（MANAGED），使用LRU算法會(huì)帶來(lái)嚴(yán)重的性能波動(dòng)，如下例子：

BeginScene();
Draw(Box0);
Draw(Box1);
Draw(Box2);
Draw(Box3);
Draw(Circle0);
Draw(Circle1);
EndScene();
Present();

假設(shè)VM只能裝下其中5個(gè)幾何體的數(shù)據(jù)，那么根據(jù)LRU算法，在繪制Box3之前必須清空部分?jǐn)?shù)據(jù)，那清空的必然是Circle0……，很顯然清空Box2是最合理的，所以這是RUNTIME使用MRU算法處理后續(xù)Draw Call能很好的解決性能波動(dòng)問(wèn)題，但資源是否被使用是按FRAME為單位來(lái)檢測(cè)的，并不是每個(gè)DRAW CALL都被記錄，每個(gè)FRAME的標(biāo)志就是BEGINSCENE/ENDSCENE對(duì)，所以在這種情況下合理使用BEGINSCENE/ENDSCENE對(duì)可以很好的提高VM不夠情況下的性能。根據(jù)DX文檔的提示我們還可以使用QUERY機(jī)制來(lái)獲得更多關(guān)于RUNTIME MANAGED RESOURCE信息，但好像只在RUNTIME DEBUG模式下有用，理解RUNTIME如何MANAGE RESOURCE很重要，但編寫(xiě)程序的時(shí)候不要將這些細(xì)節(jié)暴露出來(lái)，因?yàn)檫@些東西都是經(jīng)常會(huì)變的。最后還要提醒的是，不光RUNTEIME會(huì)MANAGE RESOURCE，DRIVER也很可能也實(shí)現(xiàn)了這些功能，我們可以通過(guò)D3DCAPS2_CANMANAGERESOURCE標(biāo)志取得DRIVER是否實(shí)現(xiàn)資源管理功能的信息，而且也可以在CreateDevice的時(shí)候指定D3DCREATE_DISABLE_DRIVER_MANAGEMENT來(lái)關(guān)閉DRIVER資源管理功能。  

D3DLOCK探索D3D RUNTIME工作

如果LOCK DEFAULT資源會(huì)發(fā)生什么情況呢？DEFAULT資源可能在VM或AM中，如果在VM中，必須在系統(tǒng)內(nèi)容中開(kāi)辟一個(gè)臨時(shí)緩沖返回給數(shù)據(jù)，當(dāng)應(yīng)用程序?qū)?shù)據(jù)填充到臨時(shí)緩沖后，UNLOCK的時(shí)候，RUNTIME會(huì)將臨時(shí)緩沖的數(shù)據(jù)傳回到VM中去，如果資源D3DUSAGE屬性不是WRITEONLY的，則系統(tǒng)還需要先從VM里拷貝一份原始數(shù)據(jù)到臨時(shí)緩沖區(qū)，這就是為什么不指定WRITEONLY會(huì)降低程序性能的原因。CPU寫(xiě)AM也有需要注意的地方，因?yàn)?span lang=EN-US style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px">CPU寫(xiě)AM一般是WRITE COMBINING，也就是說(shuō)將寫(xiě)緩沖到一個(gè)CACHE LINE上，當(dāng)CACHE LINE滿了之后才FLUSH到AM中去，第一個(gè)要注意的就是寫(xiě)數(shù)據(jù)必須是WEAK ORDER的（圖形數(shù)據(jù)一般都滿足這個(gè)要求），據(jù)說(shuō)D3DRUNTIME和NV DIRVER有點(diǎn)小BUG，就是在CPU沒(méi)有FLUSH到AM時(shí)，GPU就開(kāi)始繪制相關(guān)資源產(chǎn)生的錯(cuò)誤，這時(shí)請(qǐng)使用SFENCE等指令FLUSH CACHE LINE。第二請(qǐng)盡量一次寫(xiě)滿一個(gè)CACHE LINE，否則會(huì)有額外延遲，因?yàn)?span lang=EN-US style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px">CPU每次必須FLUSH整個(gè)CACHE LINE到目標(biāo)，但如果我們只寫(xiě)了LINE中部分字節(jié)，CPU必須先從AM中讀取整個(gè)LINE長(zhǎng)數(shù)據(jù)COMBINE后重新FLUSH。第三盡可能順序?qū)懀S機(jī)寫(xiě)會(huì)讓WRITE COMBINING反而變成累贅，如果是隨機(jī)寫(xiě)資源，不要使用D3DUSAGE_DYNAMIC創(chuàng)建，請(qǐng)使用D3DPOOL_MANAGED，這樣寫(xiě)會(huì)完全在SM中完成。

普通紋理（D3DPOOL_DEFAULT）是不能被鎖定的，因?yàn)槠湮挥?span lang=EN-US style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px">VM中，只能通過(guò)UPDATESURFACE和UPDATETEXTURE來(lái)訪問(wèn)，為什么D3D不讓我們鎖定靜態(tài)紋理，卻讓我們鎖定靜態(tài)VB IB呢？我猜測(cè)可能有2個(gè)方面的原因，第一就是紋理矩陣一般十分龐大，且紋理在GPU內(nèi)部已二維方式存儲(chǔ)；第二是紋理在GPU內(nèi)部是以NATIVE FORMAT方式存儲(chǔ)的，并不是明文RGBA格式。動(dòng)態(tài)紋理因?yàn)楸砻鬟@個(gè)紋理需要經(jīng)常修改，所以D3D會(huì)特別存儲(chǔ)對(duì)待，高頻率修改的動(dòng)態(tài)紋理不適合用動(dòng)態(tài)屬性創(chuàng)建，在此分兩種情況說(shuō)明，一種是GPU寫(xiě)入的RENDERTARGET，一種是CPU寫(xiě)入的TEXTURE VIDEO，我們知道動(dòng)態(tài)資源一般是放置在AM中的，GPU訪問(wèn)AM需要經(jīng)過(guò)AGP/PCI-E總線，速度較VM慢許多，而CPU訪問(wèn)AM又較SM慢很多，如果資源為動(dòng)態(tài)屬性，意味著GPU和CPU訪問(wèn)資源會(huì)持續(xù)的延遲，所以此類資源最好以D3DPOOL_DEFAULT和D3DPOOL_SYSTEMMEM各創(chuàng)建一份，自己手動(dòng)進(jìn)行雙向更新更好。千萬(wàn)別 RENDERTARGET以D3DPOOL_MANAGED 屬性創(chuàng)建，這樣效率極低，原因自己分析。而對(duì)于改動(dòng)不太頻繁的資源則推薦使用DEFAULT創(chuàng)建，自己手動(dòng)更新，因?yàn)橐淮胃碌男蕮p失遠(yuǎn)比GPU持續(xù)訪問(wèn)AM帶來(lái)的損失要小。 

不合理的LOCK會(huì)嚴(yán)重影響程序性能，因?yàn)橐话?span lang=EN-US style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px">LOCK需要等待COMMAND BUFFER前面的繪制指令全部執(zhí)行完畢才能返回，否則很可能修改正在使用的資源，從LOCK返回到修改完畢UNLOCK這段時(shí)間GPU全部處于空閑狀態(tài)，沒(méi)有合理使用GPU和CPU的并行性，DX8.0引進(jìn)了一個(gè)新的LOCK標(biāo)志D3DLOCK_DISCARD，表示不會(huì)讀取資源，只會(huì)全寫(xiě)資源，這樣驅(qū)動(dòng)和RUNTIME配合來(lái)了個(gè)瞞天過(guò)海，立即返回給應(yīng)用程序另外塊VM地址指針，而原指針在本次UNLOCK之后被丟棄不再使用，這樣CPU LOCK無(wú)需等待GPU使用資源完畢，能繼續(xù)操作圖形資源（頂點(diǎn)緩沖和索引緩沖），這技術(shù)叫VB IB換名（renaming）。 

很多困惑來(lái)源于底層資料的不足，相信要是MS開(kāi)放D3D源碼，開(kāi)放驅(qū)動(dòng)接口規(guī)范，NV / ATI顯示開(kāi)放驅(qū)動(dòng)和硬件架構(gòu)信息，這些東西就很容易弄明白了。

順便做個(gè)書(shū)的廣告 《人工智能：一種現(xiàn)代方法》中文版 卓越網(wǎng)已經(jīng)有貨，AI巨作，不過(guò)閱讀需要相當(dāng)?shù)幕A(chǔ)，對(duì)思維非常有啟迪，想買(mǎi)的朋友不要錯(cuò)過(guò)。后面我會(huì)將學(xué)習(xí)重點(diǎn)從圖形轉(zhuǎn)到AI上來(lái)，對(duì)AI有興趣的朋友一起交流。