文章目錄
- 前言
- 一、GPGPU是什么?
- 1.1 GPU和GPGPU之間的差異
- 1.2 GPU和CPU之間的集成方式
- 1.3 GPU包含什么(列舉和VMIPS向量體系結構的差異)
- 二、Vortex GPGPU是什么?
- 2.1 Vortex GPGPU的技術邊界和驗證環境
- 2.2 Vortex GPGPU的指令集設計(對比GPU的指令集)
- 2.3 Vortex GPGPU Core的6級流水微架構設計
- 2.4 Vortex GPGPU的微架構設計
- 2.5 Vortex GPGPU的Cache串行流水線設計和Cache多端口設計方法
- 三、Vortex GPGPU代碼包含什么?
- 3.1 Vortex GPGPU的代碼結構
- 3.2 Vortex GPGPU的握手協議
- 3.3 Vortex GPGPU代碼中slave/master規范
- 3.4 Vortex GPGPU代碼支持的debug
- 總結
前言
這次開始針對Vortex GPGPU
進行架構分析、硬件代碼分析、仿真代碼分析和運行時代碼分析。
Vortex GPGPU
的官方文檔可以見:Vortex GPGPU
Vortex GPGPU
的github可見:github,其中vortex
包含源碼和必要的.md
文件,其中vortex_tutorials
包含作者在MICRO
頂會上匯報的slide
本系列文章首先參考了知乎帖子,在略微深入了解Vortex GPGPU
之后就覺得這可能是學習GPGPU
系統工作的好機會。同時也為下一個研究工作做準備工作。
一、GPGPU是什么?
1.1 GPU和GPGPU之間的差異
顧名思義,Vortex GPGPU
是一種簡化版本的GPGPU。在此之前,可以簡單回顧GPU
的基本知識。(個人建議如果要深入研究GPGPU
架構,還是先去把《計算機體系結構:量化研究方法》這一本書內關于數據級并行
的知識去回顧一遍)由于GPU
除了包含用于加速深度學習中矩陣乘的tensor core
和支持其他計算的cuda core
之外,還包含圖形渲染
等技術。GPU在處理視覺密集型任務,如視頻游戲、三維動畫、圖形設計和視頻編輯時表現出色。此外,GPU的并行計算能力在科學模擬、數據分析、深度學習和機器學習等領域表現出色。
而GPGPU
是GPU
的一個概念,指的是將GPU
用于除了圖形渲染之外的通用計算任務。GPGPU
利用GPU
的并行處理能力來加速科學模擬、數據分析和機器學習等計算密集型任務。這種技術允許開發者通過使用專門的編程框架,如CUDA
或OpenCL
,來編寫能夠在GPU
上執行的代碼,從而利用GPU
的并行架構來加速計算。換句話說,GPGPU
專注于使用GPU
進行非圖形的通用計算任務
。
1.2 GPU和CPU之間的集成方式
注意GPU
是圖靈完備
的,圖靈完備
是指理論上只要提供足夠多的時間和內存,任何計算都可以完成
。但是這并不代表GPU
可以脫離CPU
而存在,這是因為GPU
并不是一個獨立的計算設備
,往往需要和CPU
集成在一個芯片內。CPU
負責GPU
上的計算啟動,并將數據傳輸到GPU
上。關于兩者的架構圖根據場景分為2類:
圖源《General-Purpose Graphics Processor Architecture》
圖1.1(a)顯示一個包含CPU和GPU的典型系統圖,此處GPU
是“獨立GPU”
,其中也包括用于連接CPU
和GPU
的總線如PCIE
。CPU
和GPU
分別帶有獨立的DRAM內存空間
,CPU
的內存空間稱為“系統內存System Memory”
,GPU
的內存空間稱為“設備內存Device Memory”
。并且,“系統內存”
和“設備內存”
通常會使用不同的DRAM技術
,比如CPU
使用DDR
(這是因為CPU
優先優化
對DDR的訪問延遲
),GPU
使用GDDR
(這是因為GPU優先優化
對GDDR的訪問吞吐量
)。
圖1.1(b)是一個典型的集成CPU和GPU的邏輯圖,比如AMD
的Bristol Ridge APU
或者移動設備的GPU
(“移動GPU”
),此處的CPU
和GPU
使用單一的DRAM內存空間
,因此必須使用相同的內存技術
,由于集成CPU和GPU的芯片出現在低功耗移動設備
上,所以對這種內存的優化往往針對功耗
展開(LPDDR
)。
1.3 GPU包含什么(列舉和VMIPS向量體系結構的差異)
現在來看看GPU
包含了什么?
包含指令緩存
、warp調度程序
、SIMD車道或者說線程處理器
、各個層次的存儲器
、互連網絡
等。
一個高度抽象的全架構圖如下:
類似于向量體系結構
,GPU
有類似概念。
網格
:在GPU上執行的可向量化循環,由一個或者多個可以并行執行的線程塊
組成。
線程塊block
:可以在多線程SIMD處理器上執行的向量化循環,由1個或者多個SIMD指令線程組成。它們可以通過局部存儲器通信。
CUDA線程
:對應于1個SIMD車道上執行的1個元素。
Warp
:一種傳統線程,僅包含多線程SIMD處理器上執行的SIMD
指令。
PTX
:在多個SIMD車道上執行的1條SIMD指令。
SM流式多處理器
:多線程SIMD處理器執行SIMD指令的線程,和其他SIMD處理器無關。
Warp調度程序
:當SIMD指令線程做好準備后,用于調度
和發射
這些線程的硬件,包括一個計分板
,用于跟蹤SIMD線程執行。
關于thread
、block
和warp
之間的差異見:
另外注意GPU
有2級硬件調度程序
:
線程塊調度程序
:將線程塊
分配給多線程SIMD處理器
,確保線程塊
被分配給其局部存儲器
擁有相應數據的處理器;SIMD處理器
內部的SIMD線程調度程序
(就是Warp調度程序
),用以調度何時運行SIMD指令線程。
當然GPU
和向量體系結構
這兩者也是有差異的:
GPU 向量體系結構 | |
---|---|
共同點 | 1、可以解決數據級并行問題;2、都擁有Gather-Scatter數據傳送;3、都支持mask寄存器; |
差異點 | 1、GPU的寄存器數量要比VMIPS多;2、由于沒有一種接近的標量處理器,GPU有時會在運行時以硬件實現一些功能,VMIPS通常在編譯時用軟件來實現這些功能;3、與大多數VMIPS不同的是,GPU還依賴單個“多線程SIMD處理器“中的”多線程“來隱藏存儲器延遲; |
展開SIMD車道
其余關于GPU
怎么處理分支,為什么引入mask
寄存器等之后有需補充。
二、Vortex GPGPU是什么?
2.1 Vortex GPGPU的技術邊界和驗證環境
以上是Vortex GPGPU
團隊提出的GPGPU
架構,整個系統包括Host
端和GPGPU Processor
端,Host
端通過設計兩種不同平臺的驅動來支持AMD
的OpenCL
和NVIDIA
的CUDA
,事實上作者開發了不止一種驅動,根據底層環境分為四種,后面再展開!在CUDA
和OpenCL
的運行時
之上就是兩類程序。而在Processor
端,作者做了層級設計,包括計算和存儲。存儲包含設備內存
、共享memory
和Register File
,計算層面則通過設計多個Core
實現高度數據級并行
,圖示中的AFU
是用于Host
端給GPGPU
的multi-banking DRAM
填充數據的單元。Core
的架構細節包括Warp調度程序單元
、取指
、譯碼
、寄存器堆
、ALU
、FPU
、LSU
、SFU
和共享存儲
。彼此之間的連接關系見后面。
以上是Vortex GPGPU
設計的驗證環境。
1、最右側是作者團隊設計的一個
周期精確
的Vortex GPGPU
模擬器,基于SIMX Driver
驅動支持Vortex應用程序
的運行。
2、從最右側過來,左邊第一個是純Vortex GPGPU
的驗證環境,作者借助Verilator
這個開源波形驗證工具向上搭建RTLSIM驅動
來支持Vortex應用程序
的運行。
3、再往左邊過來就是,使用AFU
實現基本的數據可供給的系統,作者依舊借助Verilator
這個開源工具向上搭建VLSIM驅動
來支持Vortex應用程序
的運行。
4、最左側就是在FPGA
平臺上基于OPAE驅動
來支持Vortex應用程序
的運行。
這樣的驗證環境對我本人來說,是全新的。因此,對我而言,有愈發學習框架和代碼的必要性。(此前,我只知道最左側的驗證環境和軟件開發流程
)
2.2 Vortex GPGPU的指令集設計(對比GPU的指令集)
上述只列舉了部分RISC-V
指令集擴展,主要是控制流指令
。
對比《計算機體系結構:量化研究方法》
上的指令集:
2.3 Vortex GPGPU Core的6級流水微架構設計
首先這個和超標量處理器類似,屬于多發射的處理器。作者自己定調是6級順序發射-亂序接收的GPGPU
。每一級流水功能見下面圖片:
這是調度階段,包括前述提到的Warp調度程序
和Warp Table
。關于IPDOM(Immediate Postdominator) Table
和Inflight Tracker
,根據官網論文的細節看:
IPDOM Table
是為了解決SIMT(單指令多線程)處理器
中的控制流分歧問題
。具體來說是因為:
控制流分歧導致性能降低
:控制流分歧發生在同一個硬件warp中的線程想要執行不同的指令路徑時。由于線程可能因為條件判斷、循環等操作而產生不同的執行流程,這會導致SIMT處理器中的某些線程空閑,從而降低流水線的利用率。如果不加以處理,控制流分歧會導致處理器性能的顯著下降。
IPDOM Table怎么解決這個問題
:為了解決這個問題,引入了IPDOM棧。IPDOM棧的作用是跟蹤warp中線程的執行狀態,以便在發生控制流分歧時能夠恢復到正確的執行路徑。具體來說,每個warp都有一個私有的線程掩碼寄存器,該寄存器存儲當前正在運行的線程的掩碼。當執行到分割指令時,當前線程掩碼的狀態、新線程掩碼的逆,以及下一條指令的地址(PC+4)會被推入到IPDOM棧中。當執行合并指令時,會從IPDOM棧中彈出這些信息,以恢復到正確的執行狀態。
IPDOM Table引入的好處
:引入IPDOM棧的目的是為了簡化硬件設計,同時有效處理控制流分歧。通過維護一個棧來跟蹤和恢復執行狀態,可以在不顯著增加硬件復雜度的情況下,解決控制流分歧帶來的性能問題。這種設計允許SIMT處理器更高效地處理線程執行中的條件分支和循環,提高了處理器的整體性能和利用率。
而Inflight Tracker
主要是為了跟蹤in flight
指令,也就是跟蹤執行中的指令。
Warp Scheduler:
1、Schedule the next PC into the pipeline
2、Track stalled, active warpsIPDOM Stack
1、Save split/join states for divergent threadsInflight Tracker
1、Track in-flight instructions
這是取指階段,包括設計Cache,處理ICache請求和響應。作者額外設計了預防死鎖
的設計(具體細節看代碼的時候展開)。
1、Retrieve instructions from memory
2、Handle I-cache requests/responses
這是譯碼階段,主要負責分析指令的各個field
,從而確定操作類型
和操作數
。
1、Decode fetched instructions
2、Notify warp scheduler on control instructions
這是發射階段,包括指令buffer、計分板、寄存器堆和操作數分發。
IBuffer
1、Store decoded instructions in separate per-warp queuesScoreboard
1、Track in-use registers
2、Check register use for decoded instructionsOperands Collector
1、Fetch the operands for issued instructions from the register file
這是執行階段,包括四大類Cluster
。
ALU Unit
1、Handle arithmetic and branch operationsFPU Unit
1、Handle floating-point operationsLSU Unit
1、Handle load/store operationsSFU Unit
1、Handle warp control operations
2、Handle Control Status Registers (CSRs) operations
注意執行階段還包括:Dispatch
和Gather
單元。
這是回收階段,用于獲取執行完的結果,并完成寫回到cache的操作。
Commit
1、Write result back to the register file and update the Scoreboard.
2.4 Vortex GPGPU的微架構設計
計算部分的層次不過多解釋!
2.5 Vortex GPGPU的Cache串行流水線設計和Cache多端口設計方法
這是個很典型的cache設計,包括Tag
和Data
部分。可以先簡單回顧Cache
的流水設計,以下圖來自《超標量處理器設計》:
一個4路組相聯
的cache設計如上,訪存地址分為Tag
、Index
、Block Offset
。Index
用于選中4路
中的哪一行,也就是選中Tag Memory
中某一行,隨后使用Tag
來確定是否命中了4路
中的某一路,如果命中,則接下來在Data Memory
對應的路中根據Block offset
選中某個cacheline data block
。
用于cache
的并行化訪問流水(這里的并行指的是對Tag Memory
和Data Memory
的并行訪問,同理后面提到的串行也是這兩者的串行訪問)
一般來說,會傾向于選擇串行訪問
,原因是減少了MUX
的數量,因為在現代CPU
中,L1 ICache
一般采用4路組相聯
(我們以intel i4
為例),L1 DCache
一般采用8路組相聯
。L2 Cache
同樣會采用8路組相聯
。因此高相聯度的cache
必然會帶來多路選擇器,而串行訪問明顯降低了對2個memory
的訪問延遲
。當然缺陷也是明顯的,就是增加了load
指令的延遲,因為多了一拍。
世界線收束一下!
單從這張圖可以看出作者采用了Tag Memory
和Data Memory
的串行流水線設計
。與此同時,作者提到為了適應多發射
的需要,引入virtual multi-porting
的設計。通常cache
因為面積本來就很大,很少考慮True multi-porting
設計。因為端口數量增加會導致面積增加。盡管如此,但是還是能接受,因為對于ICache
而言,需要每個周期讀取多條指令,多端口設計基本可以保證每拍都可以取出指令。當然發射的指令數量完全取決于一次取多少
和cacheline block
字節的對齊程度
。
在超標量處理器中,會有一些部件考慮使用True multi-porting
,比如Register File
、ROB
和Issue Queue
,但這些部件容量本身就不大。
相比之下,DCache
采用這個方案對訪問延遲和面積都有極大的消極影響。一般的處理方案是multi-banking
,以AMD Opteron
為例:
以multi-banking
的形式有利于分割開物理存儲,減少訪問競爭。一張更形象的圖是:
使用多體交叉的方式來支持多端口訪問。
至于這里提到的virtual multi-porting
設計方法,不太理解為什么作者將DCache
和ICache
都進行了同樣處理(這一點先存疑,但感覺大概率是進行了同樣操作,后續等讀完代碼后再來澄清這個問題
)。為什么這么設計,作者也提到了優勢
,可能具體有多好還得回到代碼中去看看。
三、Vortex GPGPU代碼包含什么?
3.1 Vortex GPGPU的代碼結構
這里提到在FPGA
上的部署,我簡單看了作者代碼,大概率是可以支持Vortex GPGPU
和ZYNQ
構建SoC
,作者并未套用Xilinx
提供的axi full
封裝代碼,而是自己重構了。這可能是本源碼的第不知道多少個值得學習的地方。
一個是基于Intel的開發板,一個是基于xilinx的開發板。作者提到了具體支持的板子類型:
世界線收束!
3.2 Vortex GPGPU的握手協議
只是截個圖,保證后面看代碼的時候沒遺漏細節!
3.3 Vortex GPGPU代碼中slave/master規范
3.4 Vortex GPGPU代碼支持的debug
總結
本文簡單回顧GPU和CPU之間的集成方式,GPU和GPGPU之間的差異,同時根據經典書籍展開GPU的基本知識,并與VMIPS進行對比。隨后展開Vortex GPGPU的架構設計細節,并同時深入分析了作者設計的4種驗證環境。最后簡單展開Vortex GPGPU的源碼結構。