Direct3D 10系統（五） 全文完～～～

 Direct3D 10系統（五）

作者：David Blythe

本文著作權歸原作者所有，僅供個人學習使用，請勿轉載，勿用於任何商業用途。由於本人水平有限，難免出錯，不清楚的地方請大家以原著為準。歡迎大家和我多多交流。

翻譯：claymanBlog：http://blog.csdn.net/soilworkclayman_joe@yahoo.com.cn  

5.3 Resource Mapping and Access         API和管線設計比較複雜的問題之一，關係到如何在CPU和GPU之間共用資源。舉個例子，無論Direct3D還是OpenGL都允許頂點緩衝映射到程式的地址空間中，而不管緩衝具體是分配在系統記憶體還是顯存中。但是，分配的位置將會導致效能的巨大差異。現代圖形加速器上，顯存和加速器之間的頻寬可能超過50GB/s，而PCI-E則只能為系統和GPU之間提供2.8GB/s的頻寬。         此外還有一些其它的問題。比如，CPU對所訪問的資料緩衝與否，同樣會帶來很大的效能差異。同時，是否write-combine，也會造成同樣的差異。另外，當GPU訪問資源時，為了提高空間的一致性，資源載入的方法可能是form row-order to another(e.g, Morton, boustrophedon, or pi orders), or tiled [Blinn 1990; Hakura and Gupta 1997; Igehy et al. 1999]。我們認為這些方法本質上都是為了保證分割模式（tiling pattern）對應用程式透明，因此，當資源地圖到CPU時，應該是以線形方式組織的。由於分割模式同時也依賴於訪問模式，2D和3D紋理之間是有差異的，而且這種差異不僅僅是CPU和GPU之間的不同造成的。出於對效能的重要用影響，我們嘗試暴露所有這些功能，但由於其本身的複雜性，卻很難讓應用程式真正獲得效能上的提升。我使用了一個簡單的模型，儘力提供了儘可能多的功能。         我們對特定資源的寫入者和讀取者進行了分類，e.g，GPU vs.CPU以及read vs. write。如果最初只有一位客戶訪問資源，那麼問題就變得簡單了，因為可以採取對主要客戶比較有利的方式，來分配資源。同樣，如果可以預知資源將被用來讀取或寫入，也會有很大協助。幸運的是，這樣的描述完全可以覆蓋大部分典型的應用範圍。比如，渲染目標和紋理主要由GPU進行訪問，並且分別被限制為寫入目標和讀取資源。另一方面，頂點緩衝的使用就比較複雜了。雖然靜態集合體主要由GPU來讀取，但是動態幾何體則常常作為動畫的一部分，先由CPU來產生，在由GPU進行處理。這些操作將導致頻繁的CPU寫入和GPU讀取處理。         Direct3D 10根據使用類型，把資源分為3類：default, immutable, dynamic，以及staging。Default對應比較簡單的紋理，渲染目標，或者只由GPU訪問的靜態頂點緩衝。Default類型資源的初始化，通常需要複製另一資源的資料來進行。Immutable類型的資源不允許複製操作，但是在建立時，提供了另一種方法來進行初始化。Default和immutable類型的資源都不能映射到應用程式地址空間中，讓CPU對它們進行訪問。動態資源不但可以在管線中使用，也允許映射到CPU，進行唯寫的操作。適合於產生頂點資料，或者進行視頻解碼，等等。最後，staging類型的資源只允許CPU對其進行訪問，但是，可以對它的資料進行複製。Staging類型的資源對於初始化或者擷取只有GPU能訪問的資源時比較有用。         為了檢查資源可以綁到管線的哪個位置，將在建立資源時，對資源的布局（placement）和編碼方式進行驗證。這些分類包括：頂點緩衝，索引緩衝，常量緩衝，shader資源（紋理），輸出資料流緩衝，渲染目標，或者depth/stencil緩衝。這樣的分類有兩個目的：為驅動提供資源布局的資訊，簡化使用資源時的錯誤檢查。  5.4 HLSL 10         進階著色語言廣泛，迅速的被人們所接受，無疑顯示了這種語言的重要性。為了支援新管線的特性，我們對進階著色語言――HLSL也提出了一些新的目標。簡單的說，我們希望應用程式開發人員使用HLSL高效的開發程式，而不需要瞭解虛擬機器的複雜細節，比如，寄存器名稱或常量緩衝索引。我們把目標精鍊為以下幾個小點：1．   應用程式不需要瞭解資源是如何配置和分配的。2．   把bind-by-position作為主要的綁定機制，而不是現在的bind-by-name。3．   程式員不再需要編寫中間（彙編）語言代碼第一個目標主要用於解決下面這個問題：當前系統中，應用程式開發人員需要學會控制常量儲存空間中的參數布局。開發人員需要對多個shader進行全域分配和布局（global allocation and placement），以便在多個shader之間共用某些變數。通過在每個管線階段添加的多個常量緩衝，我們相信，編譯器有足夠的資訊能自動對緩衝進行布局，當然，程式員還是要控制把參數分配到常量緩衝中的操作。我們對語言進行了擴充，允許把緩衝名作為參數的一部分，進行聲明。第二個目標則是設計思想的改變，主要與效能和未來的進一步發展有關係。Bind-by-name主要用於幾個地方：對多個shader之間輸入和輸出資料進行匹配，讓vertex shader的布局與vertex shader進行匹配，等等。雖然運行時可以讓來源資料和目標資料之間的名字匹配操作進行的比較高效，並且實現源—目標對緩衝，但我們覺得這些只會帶來不必要的複雜性，並且為運行時添加額外的負載。新系統中，將在多個方面發生變化。Shader的輸出和輸入將與 簽名（ signature ）相關，這和C總的函數原形有些類似。只有當前一階段的輸出和後一階段的輸入相容時，管線才是有效。相容意味著輸入和輸出間element-by-element的對應。這裡，我們允許下一階段的管線，不使用上一階段拖尾的（trailing）的輸出資料。Bind-by-postion通用影響到IA和SO階段的頂點緩衝綁定。但是，對這幾個階段，我們將建立獨立的對象來封裝（encapsulate）綁定，讓代價較大的匹配操作只在建立時運行一次。第三個目標是比較具有爭議性的，它表示我們的實現將不支援使用使用中繼語言編寫的shader作為輸入。我們認為著色程式的發展已經達到了一定複雜程度，因此，手寫的IL很難比編譯器產生的代碼高效。此外，當我們改進最佳化技巧，聯結，以及與驅動的互動時，無法保證對手寫IL代碼的支援和相容。作為診斷技術，系統將支援編譯器產生中間代碼作為輸出，但是，我們不允許應用程式開發人員修改編譯器的輸出，並把它注入到運行時中。         如何最佳化編譯器產生的程式碼效能，有很多問題。首先，是最佳化的範圍，驅動可能允許把中繼語言轉換為特定機器語言時進行最佳化。隨著shader複雜性的增加，確保開發人員在最佳化之上，有充分的控制權，改變操作的執行順序是相當重要的。特別是需要保證關鍵代碼的恒定性（invariance），多pass演算法應該能產生同樣的中間值，以便把這些值複製到分散的shader中。我們考慮了幾種在源碼上指定中間值的方案，比如，要求以一種特定的方式來編譯子程式，而不管這個子程式是否是內連的。但是，研究最終讓我們選擇了更加常見的方法：使用與驅動編譯器相關的，可選擇的，定義良好的最佳化層級。         請注意，我們首選的使用模型是在編寫shader時，編譯HLSL代碼，在程式運行時通過驅動編譯IL代碼。這樣的目的是希望減少程式運行時，編譯shader所花費的時間。但是，在運行時再把HLSL編譯為IL也是可以的。  5.5 HLSL-FX 10         我們注意到，編程管道的成功，改變了人們的觀點，shader程式不但是引擎的一部分，同時，也是藝術家創作工具之一。為了適應這方面的應用，Effect（FX）系統對HLSL進行了擴充，允許使用它來初始化管線的固定功能部分。這和CgFX以及Cg所描述的方法很類似。雖然這些方法有共同的基礎，但HLSL-FX是進行了革新的。我們的目標是，FX首先需要滿足即時啟動並執行需求，其次，才是作為內容建立者的工具。基於一些曆史原因，這兩者在很多方面都是由差別的。創作工具常常通過犧牲效能來換取靈活性，而我們的運行時則把效能放在第一位。         通過我們積累的經驗和努力，FX系統在易用性和效能方便都有了充分的提高。最終FX，HLSL，API，運行時，以及管線都緊密的結合到一起，作為互補的解決方案。我們同樣對頻繁的狀態操作進行了改變，分離了名字尋找以及匹配操作。         再次來討論處理狀態改變的方式。構建應用程式的方法之一是渲染一系列幾何體，每個幾何體都有其各自的管線配置（一個Effect）。通過設定常量緩衝中的shader參數，紋理綁定，以及其他固定功能的狀態，來傳遞參數給Effect。為了最大化效能，應用程式應該使用一個Effect來繪製所有物體。這是情境管理系統中，傳統的狀態排序解決方案。但是，對一個Effect來說，可能有幾個層次的參數，比如，目前時間和觀察點是屬於per-frame的狀態；紋理或頂點資料則是角色的靜態狀態；位置和姿勢則是對象的動態狀態，等等。我們使用了一個單獨的常量緩衝來儲存shader每個層次的參數，當繪製物體時，將直接綁定儲存靜態參數的常量緩衝，儲存動態參數的緩衝則要經過更新後再綁定。         在實際應用中，應用程式並不能總是通過Effect來排序對象。通常還可能有其他的機制，控制著繪圖，比如物體的遠近程度，透明度，等等。我們已經把Direct3D 10系統狀態改變的代價進行了充分縮減，因此，重新設定整個管道也是很高效的。 6 System Experience(略)7 Future Work(略)8 Conclusions(略)
～～～～～～～～～～～～～～～～～～～～～～～～全文完～～～～～～～～～～～～～～～～～～～～～        呼呼，終於把主要部分都弄完了，希望理解錯誤的地方不是太多。後3個部分基本都是總結性的東西，就不再翻了。
       最近又比較茫然了，唉～～～。       Work for money or work for what i like?