深入理解D3D9對圖形程序員來說意義重大，我把以前的一些學(xué)習(xí)筆記都匯總起來，希望對朋友們有些所幫助，因為是零散筆記，思路很雜，還請包涵。

其實只要你能完美理解D3DLOCK、D3DUSAGE、D3DPOOL、LOST DEVICE、QUERY、Present（）、BeginScene（）、EndScene（）等概念，就算是理解D3D9了， 不知道大家有沒有同感。有如下幾個問題，如果你能圓滿回答就算過關(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中有三大對象，他們是D3D OBJECT、D3D ADAPTER和D3D DEVICE。D3D OBJECT很簡單，就是一個使用D3D功能的COM對象，其提供了創(chuàng)建DEVICE和枚舉ADAPTER的功能。ADAPTER是對計算機圖形硬件和軟件性能的一個抽象，其包含了DEVICE。DEVICE則是D3D的核心，它包裝了整個圖形流水管線，包括變換、光照和光柵化（著色），根據(jù)D3D版本不同，流水線也有區(qū)別，比如最新的D3D10就包含了新的GS幾何處理。圖形管線的所有功能由DRIVER提供，而DIRVER分兩類，一種是GPU硬件DRIVER，另一種是軟件DRIVER，這就是為什么在D3D中主要有兩類DEVICE， REF和HAL，使用REF DEVICE時，圖形管線的光柵化功能由軟件DRIVER在CPU上模擬的，REF DEVICE從名字就可以看出這個給硬件廠商做功能參考用的，所以按常理它應(yīng)該是全軟件實現(xiàn)，具備全部DX標(biāo)準(zhǔn)功能。而使用HAL DEVICE時，RUNTIME則將使用HAL硬件層控制GPU來完成變換、光照和光柵化，而且只有HAL DEVICE中同時實現(xiàn)了硬件頂點處理和軟件頂點處理（REF DEVICE一般不能使用硬件頂點處理，除非自己在驅(qū)動上做手腳，比如PERFHUD）。另外還有個一個不常用的SOFTWARE DEVICE，用戶可以使用DDI編寫自己的軟件圖形驅(qū)動，然后注冊進(jìn)系統(tǒng)，之后便可在程序中使用。

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

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

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

//1.創(chuàng)建事件類型的查詢事件
m_pD3DDevice->CreateQuery( D3DQUERYTYPE_EVENT, &pQueryEvent);
//2.在COMMAND BUFFER中加入一個查詢結(jié)束的標(biāo)記，此查詢默認(rèn)開始于CreateDevice
pQueryEvent->Issue(D3DISSUE_END);
//3.將COMMAND BUFFER中的所有命令清空到DRIVER中去，并循環(huán)查詢事件對象轉(zhuǎn)換到SIGNALED狀態(tài)，當(dāng)GPU完成CB中所有命令后會將查詢事件狀態(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.第一個GetData調(diào)用使用了D3DGETDATA_FLUSH標(biāo)志，表示要將COMMAND BUFFER中的繪制命令都清空到DRIVER中去，當(dāng)GPU處理完所有命令后會將這個查詢對象狀態(tài)置SIGNALED。
2.將設(shè)備無關(guān)的SETTEXTURE命令加入到RUNTIME的COMMAND BUFFER中。
3.將設(shè)備無關(guān)的DrawPrimitive命令加入到RUNTIME的COMMAND BUFFER中。
4.將設(shè)備無關(guān)的ISSUE命令加入到RUNTIME的COMMAND BUFFER中。
5.GetData會將BUFFER中的所有命令清空到DRIVER中去，注意這是GETDATA不會等待GPU完成所有命令的執(zhí)行才返回。這里會有一個從用戶模式到核心模式的切換。
6.等待DRIVER將所有命令都轉(zhuǎn)換為硬件相關(guān)指令，并填充到DRIVER BUFFER中后，調(diào)用從核心模式返回到用戶模式。
7.GetData循環(huán)查詢 查詢對象 狀態(tài)。當(dāng)GPU完成所有DRIVER BUFFER中的指令后會改變查詢對象的狀態(tài)。

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

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

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

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

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

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

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

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

D3DLOCK探索D3D RUNTIME工作

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

普通紋理（D3DPOOL_DEFAULT）是不能被鎖定的，因為其位于VM中，只能通過UPDATESURFACE和UPDATETEXTURE來訪問，為什么D3D不讓我們鎖定靜態(tài)紋理，卻讓我們鎖定靜態(tài)VB IB呢？我猜測可能有2個方面的原因，第一就是紋理矩陣一般十分龐大，且紋理在GPU內(nèi)部已二維方式存儲；第二是紋理在GPU內(nèi)部是以NATIVE FORMAT方式存儲的，并不是明文RGBA格式。動態(tài)紋理因為表明這個紋理需要經(jīng)常修改，所以D3D會特別存儲對待，高頻率修改的動態(tài)紋理不適合用動態(tài)屬性創(chuàng)建，在此分兩種情況說明，一種是GPU寫入的RENDERTARGET，一種是CPU寫入的TEXTURE VIDEO，我們知道動態(tài)資源一般是放置在AM中的，GPU訪問AM需要經(jīng)過AGP/PCI-E總線，速度較VM慢許多，而CPU訪問AM又較SM慢很多，如果資源為動態(tài)屬性，意味著GPU和CPU訪問資源會持續(xù)的延遲，所以此類資源最好以D3DPOOL_DEFAULT和D3DPOOL_SYSTEMMEM各創(chuàng)建一份，自己手動進(jìn)行雙向更新更好。千萬別 RENDERTARGET以D3DPOOL_MANAGED 屬性創(chuàng)建，這樣效率極低，原因自己分析。而對于改動不太頻繁的資源則推薦使用DEFAULT創(chuàng)建，自己手動更新，因為一次更新的效率損失遠(yuǎn)比GPU持續(xù)訪問AM帶來的損失要小。 

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

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

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