摘要

受管貼圖（Managed textures，也就是我們通常所謂的“自動管理貼圖”），在DX6中首次被引入，經過一系列的改進和增強，在DX9中自動管理的資源類型增加到貼圖，頂點緩沖，頂點索引緩沖，所有這些資源使用統一的公共接口。通過使用D3D資源管理器，應用程序可以輕松的處理設備丟失、處理稍微過量的顯存使用。

有時開發者在使用受管資源會遇到一些困難，這部分歸咎與系統的抽象特性。在大多數情況下使用受管對象是不錯的選擇，但有時出于性能考慮也會使用非托管資源。這篇文章將討論一般情況下如何處理資源，受管與非受管資源的行為差別。

內容

l         顯示內存

l         受管資源

l         驅動管制資源

l         默認資源

l         系統內存資源

l         一般性的建議

顯示內存

為了使得資源可以利用顯存，GPU需要通過內存訪問定位他。GPU訪問（Local video memory）顯存是非常高效的，并且某些資源（例如RenderTarget，深度、模板緩沖）必須在本地顯存（Local video memory）定位。由于AGP的出現，GPU可以直接訪問部分系統內存，而這部分系統內存區域就是所謂的非本地顯存（non-local video memory），當然這部分內存（顯存）也是不能挪做它用的。非本地顯存僅能被GPU訪問，與訪問本地顯存相比，其效率低一些。需要明確的是，所有AGP內存在設備丟失時都會失效，都需要在恢復他們。

一些集成顯卡使用統一內存結構（Unified Memory Architecture），這樣主內存可以被系統任何一個設備尋址。D3D支持UMA而不需要修改任何代碼，這樣我們把系統內存配置為本地顯存，硬件確保資源的定位就像傳統的結構一樣進行工作。

受管資源

大部分資源應該使用POOL_MANAGED方式創建，即受管資源。所有受管資源將被創建在系統內存，在需要的時候復制到顯存。當發生設備丟失時會自動copy系統內存到顯存。既然不是所有受管資源都需要一次送入顯存，這樣你可以提交超過渲染每幀所必須使用的最小內存容量，但是這樣會使得大量顯存內容因為分頁操作而寫到磁盤上，這是非常耗時的。這也是為什么恢復設備如此耗時，因為需要將大量磁盤數據復制到顯存。

DX會為每份資源在最后一次使用時加上時間戳，這樣當顯存分配失敗時，它會釋放那些最近最少使用的資源（LRU算法）。使用SetPriority函數可以標記資源的重要程度，重要的資源優于時間戳的判斷，所以那些比較常用的資源應該設置高優先級，而不用擔心因為時間戳過期而導致資源被釋放。在DX9中，驅動程序提供的顯存管理信息是非常有限的，運行時可能不得不清除大量資源用于分配足夠的內存。設置適合的優先級是非常有用的，這樣D3D不會清除那些馬上又需要使用的資源。應用程序可以強制調用EvictManagedResources清除所有受管資源，但是如果下一幀又需要重新加載這些資源，這將是非常耗時的，不過這個函數在那些場景明顯需要改變（比如進入下一個關卡）的情況下，還是非常有用的。

如果“當前幀”內需要非常多資源用于渲染，這將是件麻煩的事情，用前面的LRU方式調度資源效率就不太理想了，這個時候使用MRU資源調度方式取代，即優先清理那些比較活躍的資源。注意，這里“當前幀”的概念是指BeginScene和EndScene之間的需要渲染的幀。

開發人員如果想得到關于受管資源的更多信息，可以通過IDirect3DQuery9接口查詢，但是這個接口僅能用于調試模式（debug runtimes），在發布版本中，應用程序不能依靠改接口的信息做任何假定。

了解資源管理如何工作可以幫助我們調試、調整程序，重要的是應用程序不要太過依賴當前的運行庫（或者驅動程序）的資源管理方式，驅動更新有可能導致其行為發生變化，將來的D3D將會有套久經考驗的資源管理方式。

驅動程序管理的資源

D3D驅動可以自由的實現“由驅動管理貼圖”的特性，通過D3DCAPS2_CANMANAGERESOURCE段可以查詢硬件驅動是否支持這個特性，這樣驅動將代替D3D運行庫管理資源。對于級少數的硬件是支持這個特性的，對于大多數硬件則不盡相同，你可以咨詢你的產品提供商獲得這方面信息。一般情況下，你可是使用D3DCREATE_DISABLE_DRIVER_MANAGEMENT方式創建設備，這樣將由D3D運行庫來管理資源。

缺省資源管理（非受管資源）

雖然受管資源非常簡單，容易使用，高效，但是有時我們希望直接往顯存里寫東西，這種情況下我們需要使用POOL_DEFAULT方式創建資源。使用這種方式會增加程序的復雜性，代碼需要應付所有設備丟失的情況，并需要謹慎考慮何時復制數據到顯存。錯誤的指定USAGE_WRITEONLY標記或者鎖定渲染目標（Render Target）將嚴重影響性能。

鎖定POOL_DEFAULT類型的資源很可能導致GPU停止運轉，這與POOL_MANAGED類型的資源是不同的，除非使用一些特性的指示標記。根據資源當前的位置不同，鎖定后得到的指針也不相同，可能是一塊臨時的系統內存，也可能直接指向AGP內存。如果是臨時的系統內存，Unlock后將把這段數據送入顯存，這是因為如果顯卡資源不是只寫的（write-only），Lock的時候數據將不得不被送入一段臨時的內存；如果指向的AGP內存區域，臨時的拷貝是可以避免的，但是cache的行為將會降低性能。

為了避免在寫入一整行數據（a full cache line of data）進入AGP內存區導致write-combing性能下降（一般是由于發生了一次讀寫周期），順序的訪問AGP內存是推薦的做法，如果你的程序需要隨機的訪問AGP內存，而你又不希望使用受管資源，那么你可以使用系統內存作為替代方案，這樣當你生成了數據之后，可以lock后拷貝，這樣不會帶來太大的性能損失，這里的性能損失一般是由緩沖的“寫搜索”操作引起。(注，這里關于詞匯cache write-combing譯者也不知道對應的中文含義，只能按照字面意思翻譯，見諒)

對于某些類型的資源，使用LOCK_NOOVERWRITE標記會使添加數據比較有效率，但是多次的Lock，Unlock同一資源還是需要盡量避免的，適當的利用多種不同的鎖定標記對于效率優化使非常重要的，就像填充鎖定內存區域最好使用cache友好的（cache-friendly）數據訪問方式一樣。

受管資源和缺省資源混合使用

受管資源與非受管資源的混合分配使用可能導致顯存碎塊，并且擾亂受管資源使用的內存區域。最好在使用受管資源前使用非受管資源，或者使用受管資源后使用EvictManagedResources函數清除那些受管資源再使用非受管資源。記住，所有非受管資源都會常駐顯存，這樣其他內存需求就不能使用了。

注意，與以往的DX版本不同，在顯存缺乏時，如果分配非受管資源失敗，DX9會自動清除受管資源，這有可能導致潛在的顯存碎塊，甚至把資源放入不適當的地方（比如非本地內存的靜態貼圖區）。所以，最好在使用受管資源之前分配全部的非受管資源。

動態缺省資源

如果數據需要很高頻率更新，那最好使用非受管資源，并使用USAGE_DYNAMIC標記，這樣驅動會決定最適合的地方放置這些需要經常更新的數據。這通常意味著放置在非本地顯存中，這樣對于GPU來說，訪問速度可能相對要慢一些。而對于UMA架構，驅動將會選擇CPU訪問效率較高的特殊地方放置這些數據。

這種用法（動態缺省資源類型）一般用于軟蒙皮和基于CPU計算的粒子系統的頂點/頂點索引的Buffer填充，LOCK_DISCARD標記可以保證資源仍被使用的時候，鎖定操作不會導致系統停止暫停工作。在這種情況下，使用受管資源會更新系統內存，然后拷貝到顯存。對于系統的非本地內存，多余拷貝是不需要的。

標準的貼圖是不允許鎖定的，僅僅可以通過UpdateSurface和UpdateTexture函數更新。一些系統支持動態貼圖，它可以通過配合使用LOCK_DISCARD標記進行鎖定，但這需要檢查D3DCAPS2_DYNAMICTEXTURES硬件能力。對于高動態貼圖（如視頻、程序生成貼圖），最好使用非受管資源和系統內存資源，并且通過UpdateTexture函數更新貼圖。對于高頻度的粒子更新，UpdateTexture函數可能是最好的選擇。

在有限的總線－內存帶寬下，靜態貼圖資源應該使用POOL_MANAGED方式，這樣可以確保它最好的利用本地顯存，并有較好的效率。對于“半靜態”資源，使用動態類型資源有時會獲得更好的效率。

系統內存資源

資源可以使用POOL_SYSTEMMEM方式創建。但他們不能用于圖形管線，他們僅能做為源數據用于更新POOL_DEFAULT類型的資源，這是通過UpdateSurface和UpdateTexture函數完成的。他們的鎖定操作也非常簡單，盡管他們同樣可能因為前面提到的原因導致系統停止運轉。

雖然是在系統內存中創建資源，但POOL_SYSTEMMEM所支持的資源格式和能力（比如最大尺寸）是受硬件、驅動限制的。同樣是在系統內存中創建資源的POOL_SCRATCH則沒有這方面限制，它支持所有格式和能力，但設備卻不能直接訪問它。SCRATCH類型資源一般用于內容創建工具。

一般性的建議

了解資源管理的技術實現細節對達成你的程序的性能目標是有非常大的幫助的，規劃你的資源如何交給D3D并設計好的結構以便能及時加載必要的數據是一件非常復雜的工作，為此我們給出一些好的實踐經驗做為一般性的原則：

l         預處理你的資源。不要將耗時的加載資源、資源轉換、資源優化丟給用戶去做，雖然這樣便于開發，但確讓用戶無法忍受。預處理這些資源可以加快加載，更快使用，你的用戶也會發現你的程序跑的更快了。

l         避免在每幀創建過多的資源。對于過多的資源加載，可以把他們分到多幀里完成或者不要急于釋放那些暫時不用的資源。

l         確保在一幀結束時已經斷開了所有資源通道。（比如，頂點流，texture stages，頂點索引）。

l         對于貼圖，建議使用壓縮貼圖（DXTn）格式，建議使用mip-map或者將小貼圖拼接為大貼圖使用。

l         建議使用頂點索引，這將減少數據傳輸量。

l         對于過渡的優化資源管理是需要謹慎的。如果你的程序過分依賴驅動、硬件和操作系統的某些特征，那么這些程序、硬件的修改將會導致潛在的性能問題。
http://www.shnenglu.com/richardhe/articles/69204.html