費米架構管線圖

這張圖能看懂了，整個GPU的架構基本就熟，了，資訊量很大，我們一點一點看。

GPU是什麼？

GPU，全稱是

Graphics Processing Unit

。在最開始的時候，它的功能與名字一致，是專門用於繪製圖像和處理圖元資料的特定晶片。在沒有GPU的時候，人們想將計算機中的資料顯示在螢幕上，是使用CPU來進行相關運算的。我們要做的事情簡單概括一下，就是透過對資料進行相應的計算，把資料轉換成一個又一個圖片上的畫素，然後將這張圖片顯示在螢幕上。整個流程中的計算並不複雜，但是數量大，且計算流程重複，如果全盤交給CPU的話會給其造成很大的效能負擔。於是乎GPU誕生了。

下圖是GPU與CPU的構成差異圖：

可以看到，GPU採用了數量眾多的計算單元和超長的流水線，但只有非常簡單的控制邏輯並省去了Cache。而CPU不僅被Cache佔據了大量空間，而且還有有複雜的控制邏輯和諸多最佳化電路，相比之下計算能力只是CPU很小的一部分。CPU需要很強的通用性來處理各種不同的資料型別，同時又要邏輯判斷又會引入大量的分支跳轉和中斷的處理。這些都使得CPU的內部結構異常複雜。而GPU面對的則是型別高度統一的、相互無依賴的大規模資料和不需要被打斷的純淨的計算環境。

因為GPU是為了圖形處理而誕生的，所以想要整明白GPU的架構，首先也要對渲染管線有一定的瞭解，下面是DirectX的渲染管線流程圖，遞迴這看懂了然後我們繼續：

GPU執行機制

市面上有很多GPU廠家，他們產品的架構各不相同，但是核心往往差不多，整明白一了個基本上就可以觸類旁通了。注意下方會出現大量新鮮名詞，看不懂就先把名字記下來，對照著圖來理解。

總體介紹

從Fermi開始NVIDIA使用類似的原理架構，使用一個

Giga Thread Engine

來管理所有正在進行的工作，GPU被劃分成多個

GPC(Graphics Processing Cluster，圖形處理簇)

，每個GPC擁有多個

SM（SMX、SMM，Streaming Multiprocessor 流式多處理器 是GPU的基礎單元，隔壁AMD叫CU ）

和一個

光柵化引擎(Raster Engine)

，這些部件透過匯流排所連線，例如圖中所展示的

Crossbar（交叉式匯流排）

，用來連線連線GPC和其它功能性模組（例如

ROP(render output unit，渲染輸出單元)

或其他子系統）。

程式設計師編寫的shader程式碼是在SM上執行的。每個SM包含許多為執行緒執行數學運算的

Core

。一個執行緒對應一個Core，同時一個執行緒可以被shader程式碼呼叫進行運算。這些Core和其它部件由

Warp Scheduler

驅動，

Warp Scheduler

管理一個由32個執行緒組成

Warp（執行緒束）

，其透過將要執行的shader指令移交給

Instruction Dispatch Units(指令排程單元)

來驅動Core和其他部件。

GPU有多少這些單元，不同的晶片不一樣，總的來說，越貴的越多，效能也就越好（

上面的那一段中出現的名詞在這個圖中都可以找得到，建議對著圖理解一下下，然後再繼續進行。

SM（Streaming Multiprocessor）介紹

上圖為一個SM的構成圖，從上到下依次是：

PolyMorph Engine

：多邊形引擎負責

屬性裝配（attribute Setup）

、頂點拉取（VertexFetch）、曲面細分、柵格化（這個模組可以理解專門處理頂點相關的東西）。

指令快取（Instruction Cache）

2個

Warp Schedulers

：這個模組負責warp排程，一個warp由32個執行緒組成，warp排程器的指令透過Dispatch Units送到Core執行。

指令排程單元(Dispatch Units)

負責將Warp Schedulers的指令送往Core執行

128KB Register File（暫存器）

16個LD/ST（load/store）用來載入和儲存資料

Core

（Core，也叫

流處理器Stream Processor

）

4個

SFU（Special function units 特殊運算單元）

執行特殊數學運算（sin、cos、log等）

內部連結網路（Interconnect Network）

64KB 共享快取

全域性記憶體快取（Uniform Cache）

紋理讀取單元(Tex)

紋理快取（Texture Cache）

SMM，SMX是之後對SM的升級，區別不是很大。

現在再放上這張圖，是不是看起來就不是那麼雲裡霧裡的了呢？

GPU 邏輯管線介紹

為了簡單起見，我們做一些假設。我們假設已經填充了資料並存在於 GPU 的 DRAM 中，並且在整個流程中僅使用VS和PS。

程式在圖形 API（DirectX 或 openGL）中進行繪圖呼叫（drawcall）。在這裡對資料進行合法性檢查後，資料會被GPU可讀編碼後插入到

Pushbuffer

中。在這個過程中在 CPU 方面可能會出現很多瓶頸，這也是我們常說的DrawCall瓶頸的問題所在。

一段時間後或者顯式重新整理（explicit “flush” calls）後，驅動程式已在pushbuffer 中緩衝了足夠的work並將其傳送給 GPU 進行處理（在作業系統的某些參與下）。GPU 的

Host Interface

接收透過

Front End

處理。

資料完全到達GPU後，在

圖元分配器(Primitive Distributor)

中開始工作分配，處理indexbuffer，將處理得到的三角形分成batch，傳送給多個GPC。

在GPC中，每個SM中的

Poly Morph Engine

負責透過三角形索引（triangle indices）取出三角形的資料（vertex data），即下圖中的Vertex Fetch模組。

在獲取資料之後，在SM中以32個執行緒為一組的執行緒束（Warp）來排程，來開始處理頂點資料。

SM的warp排程器會按照順序分發指令給整個warp，單個warp中的執行緒會鎖步（lock-step）執行各自的指令，如果執行緒碰到不啟用執行的情況也會被遮掩（be masked out）。被遮掩的原因有很多，例如當前的指令是if（true）的分支，但是當前執行緒的資料的條件是false，或者迴圈的次數不一樣（比如for迴圈次數n不是常量，或被break提前終止了但是別的還在走），因此在shader中的分支會顯著增加時間消耗，在一個warp中的分支除非32個執行緒都走到if或者else裡面，否則相當於所有的分支都走了一遍，執行緒不能獨立執行指令而是以warp為單位，而這些warp之間才是獨立的。

warp中的指令可以被一次完成，也可能經過多次排程，例如通常SM中的LD/ST（載入存取）單元數量明顯少於基礎數學操作單元。

由於某些指令比其他指令需要更長的時間才能完成，特別是記憶體載入，warp排程器可能會簡單地切換到另一個沒有記憶體等待的warp，這是GPU如何克服記憶體讀取延遲的關鍵，只是簡單地切換活動執行緒組。為了使這種切換非常快，排程器管理的所有warp在暫存器檔案中都有自己的暫存器。這裡就會有個矛盾產生，shader需要越多的暫存器，就會給warp留下越少的空間，就會產生越少的warp，這時候在碰到記憶體延遲的時候就會只是等待，而沒有可以執行的warp可以切換。

一旦warp完成了vertex-shader的所有指令，運算結果會被Viewport Transform模組處理，三角形會被裁剪然後準備柵格化，GPU會使用L1和L2快取來進行vertex-shader和pixel-shader的資料通訊。

接下來這些三角形將被分割，再分配給多個GPC，三角形的範圍決定著它將被分配到哪個光柵引擎（raster engines），每個raster engines覆蓋了多個螢幕上的tile，這等於把三角形的渲染分配到多個tile上面。也就是畫素階段就把按三角形劃分變成了按顯示的畫素劃分了。

SM上的Attribute Setup保證了從vertex-shader來的資料經過插值後是pixel-shade是可讀的。

GPC上的光柵引擎（raster engines）在它接收到的三角形上工作，來負責這些這些三角形的畫素資訊的生成（同時會處理裁剪Clipping、背面剔除和Early-Z剔除）。

32個畫素執行緒將被分成一組，或者說8個2x2的畫素塊，這是在畫素著色器上面的最小工作單元，在這個畫素執行緒內，如果沒有被三角形覆蓋就會被遮掩，SM中的warp排程器會管理畫素著色器的任務。

接下來的階段就和vertex-shader中的邏輯步驟完全一樣，但是變成了在畫素著色器執行緒中執行。 由於不耗費任何效能可以獲取一個畫素內的值，導致鎖步執行非常便利，所有的執行緒可以保證所有的指令可以在同一點。

最後一步，現在畫素著色器已經完成了顏色的計算還有深度值的計算，在這個點上，我們必須考慮三角形的原始api順序，然後才將資料移交給ROP（render output unit，渲染輸入單元），一個ROP內部有很多ROP單元，在ROP單元中處理深度測試，和framebuffer的混合，深度和顏色的設定必須是原子操作，否則兩個不同的三角形在同一個畫素點就會有衝突和錯誤。

流程結束。

這個時候我們再來回顧一下這張圖：

這會兒就會比較清晰了。

［1］

［2］

參考

^

life-triangle

https：//developer。nvidia。com/content/life-triangle-nvidias-logical-pipeline

^

X-Jun的DX11教程

https：//www。cnblogs。com/X-Jun/p/9028764。html#_lab2_8_2