The Direct3D 10 System

注：SIGGRAPH 2006即將在波士頓開幕，微軟也將發布DirectX10的相關資料。為此特地翻譯了源自微軟DirectX開發社區的一篇PDF文檔，“The Direct3D 10 System”，原文地址為http://download.microsoft.com/download/f/2/d/f2d5ee2c-b7ba-4cd0-9686-b6508b5479a1/Direct3D10_web.pdf。原文的腳注有“ACM, (2006). This is the author’s version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution.”原文版權歸其作者以及相關組織所有，遵守ACM關于僅限個人使用，不得發布的條令。中文版由zhoubo22@hotmail.com翻譯，僅限個人學習之用。有刪節。

摘要：我們將向您展示第四代GPGPU的系統架構。整套架構新的特征將包括諸如，直接向內存存取流式的Primitive數據，統一頂點數據以及圖像數據資源的管理，以及新的存儲格式。我們也將向您說明一些在新的管線（Pipeline）設計中，所作的對API、Runtime、Shading Language的一些改動。

一、正文：

OpenGL 以及Direct3D的架構已經發展了好幾代。在過去五年中，技術的逐漸進步推動著處理模式由傳統的固定管線（Fixed Function）向可編程管線過渡（Progammable Pipeline）。在進步過程中，實際上體現了設計者對通用性、性能、成本的綜合考慮。到目前為止我們已經編寫了許多圖形加速的應用程序，比如演示系統，CAD，多媒體處理系統等等，以及游戲。這些程序無一例外的都需要管理數以G字節計算的數據，比如幾何體頂點數據、紋理數據、動畫數據，以及處理圖形的程序，占用大量的系統資源，以人們可以接受的速率渲染逼真的圖形。在許多的系統設計中，我們都可以看到人們如何有效的解決問題。如同舊版本的Direct3D一樣，Direct3D 10實際上是三方面工作的合作成果，硬件設計者，API/Runtime架構者，以及應用程序開發人員。參考了應用程序開發者們反映的意見，我們把一些常見的問題進行了整理：

1. 狀態機切換代價太高（High State-change overhead）。改變任何的狀態，比如頂點格式、紋理格式、Shader參數、混合模式等，代價太高。為了盡量減少狀態的改變操作，需要我們對處理順序進行排序，使用基于Shader的技術，優化整個程序的性能。比如，需要多重紋理貼圖時，可以將幾個紋理合并到一個紋理上，然后通過對定點坐標的處理，進行多次的貼圖操作。

2. 廠商之間定義的硬件加速功能過于混雜。有些時候應用程序使用了一些專有廠商自己定義的特殊功能，導致無法在大部分的硬件上有效的運行。

3. CPU 與GPU的同步問題。傳統結構在管線中提取出新的數據是有次數限制的。比如渲染場景到紋理（Render To Texture）技術，把場景拷貝出來作為紋理貼圖使用，CPU使用率并不高。盡管這樣，產生新的頂點數據或者創建立方體紋理依舊需要更多的坐標數據，以及GPU與CPU之間的同步，降低了效率。

4. 指令的數目以及數據類型的限制。比如Vertex Shader需要處理數據的精度，以及實現傳統的流程控制（Flow Control）結構。Pixel Shader也一樣。但是無論是Vertex Shader還是Pixel Shader，處理整數的能力要遠遠強于處理浮點數據能力。應用程序要么舍棄了這些代價太高的處理方法，要么以比如基于查招表的方式運行。

5. 資源限制。太多了，比如紋理單元（Texture Unit）數目的限制，Shader指令數目的限制等等。所以現在很多程序都不得不盡量將算法簡化，或者使用多Shader的方法進行處理。

二、背景

整個可編程GPU系統的發展可以分為四個階段，如下表：

Feature	1.1 2001	2.0 2002	3.0 2004	4.0 2006
Instruction slot	128		≥512	≥64K
	4+8	32+64	≥512
Constant registers	≥96	≥256	≥256	16x4K
	8	32	224
Tmp registers	12	12	32	4K
	2	12	32
Input registers	16	16	16	16
	4+2	8+2	10	32
Render targets	1	4	4	8
Samplers	8	16	16	16
textures			4	128
	8	16	16
2D texture size			2Kx2K	8Kx8K
Integer ops				√
Load op				√
Sample offsets				√
Transcendental ops	√	√	√	√
		√	√
Derivative op			√	√
Flow control		Static	Static/dynamic	dynamic

硬件實現實現了數據從Vertex Shader到Pixel Shader的高速處理。多Vertex Shaders和Pixel Shaders可以用來并行的處理獨立的頂點以及像素。一般來說GPU的像素處理單元要遠多于頂點處理單元，因為在實際情況中需要處理的像素總是要比頂點多得多。

在OpenGL與Direct3D中，可編程處理管線使用低等級的抽象層與硬件交互。這個抽象層對于程序來說是完全透明的，隱藏了各種底層的實現。而其它平臺，比如工作站，和PC平臺就完全不同，直接由硬件實現一切，硬件所有的特性都是向外暴露的。

早期由于硬件的限制，為了精簡指令數，不得不采用匯編語言進行編碼。如今隨著硬件的發展，處理程序的編寫完全可以使用高等級語言實現，比如C-like的語言進行編寫——而且，熟悉C語言的開發人員非常多。可是，當GPU編程語言等級提高了之后，又產生了一些問題，比如，硬件的編譯模型更像虛擬機，Shader匯編語言比起機器語言跨平臺的特性更好。HLSL語言可以被預編譯，等到運行時再被GPU驅動翻譯成機器語言執行。GLSL語言則不同，它是在運行的時候從源代碼直接翻譯成機器語言執行。

三、管線

Direct3D 10 依舊保留了傳統的硬件加速管線，不過增加了2個新的流程。如圖所示：

Input Assembler （IA）將從輸入流（Input Stream）中將所有的1D頂點數據轉換為浮點格式（float32）。每一個流對象指定了一個頂點結構，最多包含16個頂點緩沖結構。一般來說GPU按照頂點的輸入順序處理，必要時應該使用索引緩沖（Index Buffer）提高性能。IA也支持對物體進行快速復制，類似于實例繪制（Instancing）技術，不過更有效率。

Vertex Shader （VS）一般用來做空間變換。VS讀取一個頂點，輸出一個頂點。VS可以和其他的Shader分享數據，允許訪問多達128個紋理，以及16個內部緩沖。更多的內容請看第4節。

Geometry Shader （GS）讀取Primitive中的頂點，輸出定點或者Primitive。可輸入輸出的Primitive可是是不同類型的，但它們對于Shader來說都是一樣的。GS程序可以在輸入的Primitive中插入新的頂點，產生新的Primitive，進而產生新的幾何結構，也可以剔除輸入的Primitive。

Stream Output （SO）的作用是將GS輸出的數據拷貝到輸出緩沖。可是由于硬件的限制，SO只可以實現1個最多包含16個Elements的Multi-Element的輸出流，或者是4個single-element輸出流。IA支持8bit以及16bit數據的讀取，轉換成float32格式，SO只能寫入32bit格式的數據。在GS可以方便的實現數據格式的轉換以及Packing。

Set-up and Rasterization Stage （RS）執行諸如Clipping、Perspective divide、viewport transform、primitive set-up、Scissoring、depth offset、fragment generation（不好意思沒有翻譯）。GPU的設計中一般都有Early Depth處理。RS負責處理頂點，Primitive的Attributes，輸出光柵化處理后的像素。

Pixel Shader （PS）讀取Pixel Fragment的attribute，輸出最多包含8個attribute的Fragment。Attribute值被寫入不同的色彩緩沖，如果不符合輸出條件則丟棄（discard）這個像素。一般Depth以及Stencil值在RS中已經被計算好。雖然說在PS中依舊可以進行Depth的計算以及重新寫入，不過為了優化請盡量在RS中進行這些運算。Stencil值不可以被改寫。

Out Merger （OM）讀取PS處理過的像素，進行傳統的Stencil測試和Depth測試，以及Alpha混合。OM綁定了一個Depth/Stencil緩沖，以及最多8個Attribute緩沖。PS必須向每個渲染目標都輸出值。當在所有渲染目標之間使用同一個混合函數的時候，您可以分別設置各個渲染目標是否啟用或者禁用混合。

內存結構與數據Flow

GPU 需要處理大量儲存在諸如頂點緩沖、索引緩沖、紋理單元里的數據。GPU一般將數據儲存在自己的高速顯存中。這些數據包括1/2/3D的紋理貼圖，1D的索引以及頂點數據等等。在Direct3D 10中把所有的這些都統統稱為資源（resources），目的是為了提高處理效率。因為提高效率無非有兩個方法，在單通道里盡量做最多的事情，或者單通道里創建了Resources后在多通道里復用。

幾種Resources可以提高單通道渲染的效率。Arrayed Resources。紋理貼圖，以及渲染目標可以被當作線性數組（Linear Arrays）綁定到一個渲染通道中。Shader里用來取得紋理索引的指令被擴展為Computed Array Index。現在有不少的開發人員為了效率將一些紋理放到一張大的紋理上，渲染時通過紋理坐標分割紋理。這種改變可能會給他們帶來一些壓力。當然，Texture Arrays不需要考慮這種特殊情況，因為它是為了處理大量尺寸相同的紋理而設計的。

當一個渲染目標數組（Array of Render Targets）綁定到OM時，GS處理時可以對Primitive進行排序或者復制。比如，當在單通道中渲染場景生成立方體貼圖時，可以把它當作一個包括6個2D渲染目標的數組。（Array of 6 2D Textures）。當對物體進行立方體貼圖時，GS將決定使用哪一個面的像素進行貼圖。需要了解的是，GS處理渲染目標數組與PS的多渲染目標輸出之間是獨立的進行的。

為了使用渲染場景到紋理（Render to cube map）功能以及為了更加方便的使用數組，添加了一個新的概念——View。編碼時，不需要制定資源，不需要額外的輔助參數，Direct3D 10允許創建資源時，不需要指定類型，比如究竟是float16還是snorm16，所以可能會發生非常有限的類型隱式轉換，只有相同大小的類型可以轉換，其余的不可以，比如2個float16數字絕對不可以當作1個float32數字。資源也無法直接用于管線處理，它們必須通過View綁定。

流輸出對象特別適合處理連續的1D數據比如頂點坐標等，優點包括，可以支持輸出非常多的數據類型。流對象支持不支持對輸出數據進行隨機訪問。如果有需要在VS里可以做足夠的處理。

Shader 里操作的數據是32bit的（無論是浮點數還是整數）。此時就需要提供更加豐富的數據類型，減少內存占用以及帶寬。數據會被自動對齊為整數的大小（32bit）。幾乎所有的數據類型都可以作為頂點數據、紋理數據，作為流輸出，以及渲染目標。如下表：

Name	Widths	Range
UnormN,snormN	8,16	[0,1] and [-1,1]
FloatN	32,16,11,10	S32e8,s10e5,6e5,5e5
UintN,sintN	8,16,32	[0,2^n-1] and [-2^n-1,-2^n-1]
RGBE	32	999e5
SRGB	8	[0,1] no-linear

unorm 、snorm以及半浮點數是用的最多的格式。比如在需要HDR的程序中，半浮點數可以提供最好的精度以及最合理的帶寬占用，而且硬件也支持豐富的過濾操作。DirectX10里面的32bit數字有兩種格式，第一種是，RG通道各占11bit，B占10bit，剩下1bit存儲共享的指數；第二種，RGB各占9bit，5bit儲存指數。這兩種格式都能夠達到float16格式的精度。其中，低精度的11-11-10格式適合用來儲存HDR色彩數據。當然Direct3D 10依舊支持低動態范圍的壓縮紋理格式。

設計考慮

對比以前的架構，Direct3D 10要求所有的Features都由硬件來實現。目前問題有兩個，硬件需要支持32bit紋理過濾以及渲染目標的多重采樣以及反鋸齒。所有的可編程結構可以模擬的固定管線處理功能，都將從核心以及API中去處，包括光照，矩陣變換，Alpha混合。固定處理管線可以很容易的用軟件模擬。不過一些較重要的傳統處理管線依舊保留。我們設計曾經考慮過把IA設計成完全可編程的，但是無法證明一切會變得更加的簡單還是復雜，而在VS里可以計算。事實上，VS可以不需要進行任何的內存讀取操作，直接從IA中讀取數據計算。話雖如此，為了性能我們依舊保留了一些IA的復雜特征，這樣可以完全發揮可編程的優勢，在處理頂點時硬件可以達到最高的效率。

Gs 的設計更為復雜。GS可以進行并行處理，保存數據（類似于Primitive）的輸入順序，這樣有多個GS單元處理數據時不會發生順序的錯誤。這種并行的設計要求必須有一個輸出緩沖，而且數據的順序必須同輸入的數據相同。讓GS盡可能的多的代替RS的工作，比如Viewport變換等。GS可以做一部分Clipping，比如計算頂點到Clip-Plane的距離，把Clip-Space空間中的坐標傳遞到RS。RS采用的依舊是傳統處理管線，對比GS來說精度不高，所以不可能讓GS模擬RS生成Image-Space坐標。Om也是經常被討論的部分。OM是整個管線中唯一可以進行內存讀寫的部分，也經常被要求設計成可編程單元。不過這樣一來管線的復雜度就大大的提高，而且內存系統的效率也會打折扣。曾經提過是否可以把OM結合到PS中，可是如果這樣，多重采樣以及混合操作就會變得非常的復雜（因為PS不可以獲得Fragment內存地址），而且Early Depth/Stencil已經可以顯著的提高性能。

Shader Model 4

在以前版本的Direct3D中，可編程管線單元（VS PS）是用一個特殊的虛擬機實現的。每個虛擬機使用馮諾伊曼架構，類似于匯編語言的指令集，擁有輸入輸出寄存器，堆棧，以及可以獲取內存資源的Binding Points。Direct3D 10為每個可編程管線單元定義了一個“Common Core”，新增加了以下內容：

• 32bit 整數指令，算術運算，Bitwise計算，Conversion計算。

• 可尋址的（Indexable）通用寄存器，大小為4096x4

• 分開執行Unfiltered指令與filtered內存讀取指令（讀取以及采樣指令）

• 支持Shadow Map采樣

• 16 個Constant（parameter）緩沖 4096x4

• 減少Texture Bind Points（128），和Sampler State（16）

這個統一模型（Unified Model）代替CPU執行所有的算術運算、邏輯運算、以及Flow Control。資源（Resource）比如寄存器、Texture Bind Points，以及指令存儲器等等這些不應該是軟件開發人員頭痛的問題，接下來的幾年，硬件廠商會自己對產品進行性能與成本的折中。Texture Bind Point數目的提高顯然不會對Texture Filtering Combinations有太多的要求。加大Constant存儲空間與更新Constant的效率之間的沖突不可避免。目前的系統一個明顯的問題就是用一般的更新操作更新Constant值效率不高，而如果程序使用了多個Shader那么效率會更加低。在實際情況中Group Of Constant更新的頻率并不相同，有時是每幀，或者每個物體，或者每個實例。由此我們把Constant分開存儲到不同的緩沖中，分開進行操作。而Constants訪問的頻率遠遠高于紋理，Constants一般使用uniform索引，而紋理一般使用紋理坐標。這也要求硬件設計者把Constant與紋理進行分離。同時我們也提高了浮點數的精確度，對比IEEE754的0.5ulp，我們達到了1.0ulp。在進行平方開放運行時，精度可以達到2.0ulp。

核心API與Runtime

核心API與Runtime作為一個瘦抽象層（Thin Abstract Layer）工作于硬件上，對上層的操作進行解釋。API與Runtime負責處理內存資源，建立View、Shaders，綁定到管線上，以及初始化渲染，提供硬件查詢等等。我們希望提高命令執行的效率，把命令分為兩類。一類是處理資源的命令，一類是操作管線的命令。Runtime先初始化一個緩沖，API命令對緩沖執行各種操作，等到緩沖已滿或者需要同步的時候把緩沖上傳到GPU中，比如當回讀渲染目標的時候。Runtime模型在PC系統上發展了十幾年，我們的目標是提高命令的效率，當命令執行時不需要額外的處理。過去這是不可能實現的需求，不過我們改進了一些設計，讓這個目標離我們更加近。其中有一些關鍵原因：

• API 與硬件之間不兼容

• 處理延遲

• 應用程序的真正需要

第一個問題已經被輕松的解決，這樣在應用程序開發者，Runtime，驅動程序，以及硬件提供者之間，不敢說從此100%的兼容，最起碼能夠滿足不是那么苛刻的要求（壟斷加大棒）。第二個問題經常碰到，尤其是需要做許多處理的時候。不過這樣的好處是，各個處理過程之間互不干擾是正交的。可是，這給CPU帶來了許多負擔，比如當紋理綁定發生更改時需要重新編譯Shader以符合新的紋理格式。我們希望盡可能多的消除硬件中內在關聯的狀態操作，同時在運行期把這些操作歸入Optional Layer進行單獨的操作。狀態機機制也發生了改變。在OpenGL與以前的Direct3D軟件的顆粒度非常令人滿意，比如改變混合方式的操作，樣本過濾操作等。為了提高效率可以使用OpenGL的Display List或者是Direct3D的State Block。我們當然希望更加的優化，提高效率。于是減少了不少固定處理管線。我們的研究發現現有的狀態機結構模型無法再進行效率的提高，所以我們把一些相關聯Functions組成一個固定集合，稱為State Object。Direct3D 10定義了5個State Object：InputLayer（Vertex Buffer Layout），Sampler，Rasterizer，DepthStencil，以及Blend。當構造這些對象的事后，驅動程序先在寄存器中初始化硬件操作需要的數值。當對象綁定到管線的時候，所有的數值被拷貝到命令緩沖里（Command Buffer），在硬件本地提供命令以及操作。還有一些難題還無法避免，比如上面說過的Constant問題，還有比如切換資源的讀寫狀態。這需要應用程序自己進行優化。

一些API的設計為了執行期的效率沒有考慮容錯，或者只為頻繁使用的API提供容錯。對比運行期的錯誤處理機制，我們更青睞在程序開發時就進行錯誤處理。首先我們把出現的錯誤分為兩類，致命的（Critical）和非致命（Non Critical）。運行期時一定會報告致命的錯誤，而非致命的錯誤會被一個特殊的攔截層攔截。開發調試時主要使用Validation Layer。即使如此，也不能全指望API自己的容錯機制，驅動程序也應該阻止一些可能發生硬件損壞的操作。我們的目的是在渲染期間盡量不發生錯誤，也就是說，錯誤檢測不應該在渲染期間執行。致命的錯誤包括Depth Buffer與渲染目標之間尺寸不符合，Shader編譯錯誤等等。

CPU 與GPU之間共享資源也是討論已久的問題。比如，OpenGL與Direct3D都允許先在程序自己的內存地址里創建一個頂點緩沖，然后全部上傳到顯卡中。雖然說性能有了很大的提高，但是帶寬的差距依舊非常巨大，顯卡與高速顯存只見的帶寬能夠達到50GB/s，而PCI-E總線最多只能在GPU與系統內存之間實現2.8G/s的帶寬。即使如此，由于CPU與GPU處理的數據格式并不相同，而且數據儲存的格式也并不相同，所以只能期望應用程序自己進行性能的優化。傳統意義里，GPU一般是資源的Writer，而CPU一般是Reader。為了優化性能，需要明確的知道，那些讀取哪些資源，寫入哪些資源。幸運的是開發人員一般都知道這一點。比如，渲染目標以及紋理一般是GPU的讀取資源，限制寫入操作。可對于頂點緩沖的就有了難題，因為GPU讀取的是靜態的網格，而一般由CPU進行動畫的計算，生成動態的網格，然后在傳入GPU。這樣一來，在CPU與 GPU之間的讀寫操作就非常頻繁，占用可憐的帶寬。Direct3D 10把資源（Resource）4類：Default，Immutable，Dynamic，Staging。Default資源包括簡單的紋理，渲染目標，靜態的頂點緩沖，一般通過Copy操作生成。而Immutable資源不允許事先通過Copy生成，但是提供了其他的生成方式。Default與Immutable資源不能被CPU訪問。Dynamic資源可以被綁定到管線，與CPU寫操作進行映射。比如讓CPU進行動畫的計算，視頻解碼等等，直接寫入Dynamic資源。Staging資源允許CPU映射，但是可以互相進行拷貝操作。

我們也對HLSL語言進行了改進，把底層實現封裝，開發人員無須了解底層虛擬機細節就可以進行開發。特性如下：

1. 無須顯式進行任何資源的賦值操作。

2. Bind-by-Position 代替了Bind-by-name

3. 盡量讓開發人員使用高級語言

開發人員一般使用在多個Shader里傳遞數值的方式進行通信。當有了多Multiple Constant Buffers后，我們相信編譯器會更加對單緩沖操作進行更好的優化，但是開發人員依舊需要制定要寫入的Constant Buffer。第二個變化是非常巨大的，與以前的發展發展方向完全不同。這主要是為了性能和未來的發展考慮。Shader里對輸入輸出變量的聲明更類似于C語言的原型（這一點GLSL已經體現出來）。兼容性，在這里的意義是輸入與輸入的數據類型要完全符合。Bind-by-position也用在了頂點緩沖對IA與SO的邦定上。盡管這樣在這些處理階段我們還是定義了特殊的Objects，以便在運行期執行昂貴的Matching操作。第三項也是和開發密切相關的，這要求我們在新的實現中不再提供Intermediate語言的支持。我們發現即使非常優化的代碼，編譯器為IL產生的機器碼效率低于其他單元的機器碼。而且當與驅動程序結合起來的時候，我們將不可能只對一個IL單元進行額外的優化。系統可以通過編譯器把IL處理過的數據作為調試信息輸出，不過不允許程序開發者在運行期進行對編譯器的輸出做任何更改。誰都希望編譯產生的代碼是最最優化的，可是這也帶來的許多問題。最重要的是驅動程序究竟能為IL產生多么優化的機器碼。Shader復雜度提高要求開發人員自己對算法、執行順序進行優化。而且，編譯關鍵部分的代碼，結果一定要相同，這樣當使用多通道算法的時候才能產生相同的中間值（Intermediate），在各個Shaders之間進行復制操作。我們考慮了一些實現方式，比如當它們需要內聯的時候，子程序被編譯為相同的碼。同時也不能忽視驅動程序的編譯器，那也是性能優化的關鍵。需要注意的是，我們提倡的使用模型是預先編譯好HLSL代碼，等到執行的時候由驅動程序編譯為機器碼，系統當然也支持運行期的動態編譯與執行。

我們同時也注意到，可編程管線的價值不僅僅在于Shader Program，也應該動態支持的特效實現比如CgFX。由此，產生了HLSL-FX 10。FX系統要考慮問題是，開發人員如何使用，以及如何提高效率。應用了FX系統后，如何有效地進行狀態處理又成為了討論的主題。為了最好的性能最好的辦法依舊是只使用一個效果，渲染好所有的物體。Effect，其實是就是一系列操作的集合。為了性能效率，程序最好一次性渲染好使用同一個效果的物體。在真實的場景中，Effect只是一個環節，其余還有諸如View Position處理，紋理貼圖等等其他操作，而且，不可能總是根據Effect渲染場景，還需要考慮諸如距離，透明狀態等等。

系統體驗

整個工程從2003年開始API的設計，以及硬件的設計，2006年公布。2004年開始測試軟件，公開于2005年。測試數據如下，不過都是舊的，因為真正合格的測試環境還沒有。

Operation	Direct3D 9	Direct3D 10 (reference)
Draw	1470	154
Bind VS Shader	6636	416
Set Constant	3297	916
Set Blend Function	787	530

在開發過程中，我們寫了許多關于GS，SO等的DEMO程序。包括Soft shadow volume，Procedural content generation，High Order normal interpolation，motion blur等。開發人員也在進行程序的移植，從DirectX9過渡到DirectX10，同時我們正在與外部的開發人員使用新的API從頭開始編寫程序，估計過幾年將會出現完全使用DirectX10的程序。

總結

我們正在總結開發設計經驗，等到Direct3D10真正發布的時候對API進行一些改動升級。軟件一直在發展，可是硬件的發展卻很緩慢。這些都是在升級時需要考慮的。長遠的，我們依舊在探討管線結構與編程模型。系統的瓶頸依然在如何有效的進行處理，硬件的發展是關鍵。比如傳統的過程紋理以及表面的處理，已經即將被位移映射等新技術代替。我們相信，隨著以后的硬件軟件的發展將會在整體上超越目前的系統。