計算機架構與系統實驗室

Computer Architecture and System Laboratory

使用者工具

網站工具


group:aionchip

差異處

這裏顯示兩個版本的差異處。

連向這個比對檢視

Both sides previous revision 前次修改
group:aionchip [2020/06/03 08:14]
admin
group:aionchip [2020/06/03 09:13] (目前版本)
admin
行 9: 行 9:
 CASLab GPU 透過電子系統層級 (Electronic System-Level, ESL)的 Full System 設計方案,軟體與硬體開發能在早期開發即進行系統驗證。利用 C 與 C++所實作的指令級模擬器(Instruction Set Simulator, ISS)可驗證指令集的功能正確性並提供時間模型(Timing Model)來做效能上的初步評估。而 SystemC 等高階硬體描述語言則提供彈性的硬體設計方法,因為是 Cycle-Accurate 行為,開發者在早期階段就能夠更準確的達到效能分析,也能作為後續如 Verilog 等暫存器傳遞語言(Register-transfer Language)的實作範本。目前 CASLab GPU 已在 FPGA 層級完成功能性的驗證,接下來會繼續優化與考慮實際硬體的成本,讓 CASLab GPU 能夠成為一顆高效能的 Edge Computing IP。 CASLab GPU 透過電子系統層級 (Electronic System-Level, ESL)的 Full System 設計方案,軟體與硬體開發能在早期開發即進行系統驗證。利用 C 與 C++所實作的指令級模擬器(Instruction Set Simulator, ISS)可驗證指令集的功能正確性並提供時間模型(Timing Model)來做效能上的初步評估。而 SystemC 等高階硬體描述語言則提供彈性的硬體設計方法,因為是 Cycle-Accurate 行為,開發者在早期階段就能夠更準確的達到效能分析,也能作為後續如 Verilog 等暫存器傳遞語言(Register-transfer Language)的實作範本。目前 CASLab GPU 已在 FPGA 層級完成功能性的驗證,接下來會繼續優化與考慮實際硬體的成本,讓 CASLab GPU 能夠成為一顆高效能的 Edge Computing IP。
  
-===== CASLab GPU 軟體開發 ===== 
-在設計開發上,CASLab GPU 軟體堆疊情形如 Fig. 1。最上層實作 TensorFlow Runtime 讓使用者在平台上面能使用 TensorFlow API 以支援機器學習、深度學習模型開發,並透過 OpenCL Runtime 支援 GPU 來達到大量平行運算效能提升,無論是 TensorFlow CNN Application 或是 OpenCL 應用程式都能在 CASLab GPU 上達到加速效果。GPU 的軟體層級如果沒有編譯器支援的話,是無法完整將整個 GPU 系統平台建立起來的,因此編譯器在整個軟硬體系統上佔有非常重要的地位。CASLab GPU開發了自己的 OpenCL LLVM Compiler 以支援 CASLab GPU 硬體。因為是自行開發,編譯器能夠設計出適合我們 GPU 硬體的執行程式,使硬體與軟體間達到良好的配合,提升執行效率。最後透過 HSA runtime 提供一共同硬體介面,在軟硬體間搭載一個橋樑與 Device Driver 做溝通,降低 OpenCL Runtime 的設計複雜度,GPU 收到軟體端的資訊後便開始運作,最後在將結果傳回 CPU 端的記憶體中,達到程式加速的效果。 
-\\ 
-\\ 
-<<fig1>> 
-\\ 
-\\ 
-==== TensorFlow Runtime ==== 
-要達到 TensorFlow 應用能執行在 OpenCL 架構底下,我們需要了解TensorFlow Stream Executor 這個由 Google 為 TensorFlow 所定義的 Kernel API共用介面實作方式,以及 TF-Coriander 這個第三方專案的搭配方案。 
- 
-以下是對這兩種專案的介紹,首先,介紹何謂 TF-Coriander。原生的TensorFlow GPU Support 僅支援採用 CUDA Programming Language 的 GPUDevice,對於其他平台開發者需自行針對目標平台設計一 Stream Executor。由於TensorFlow 提供眾多 Kernel Operation 種類,如為該平台提供更完整的支援會需要花費大量人力成本於此,且未來 TensorFlow 如有更新會難以同步與維護。為了降低新增硬體的複雜度,Perkins, Hugh.於 2017 年提出 CUDA-on-CL 架構,利用一名為Coriander 之 Source-to-Source Compiler 將原生的 CUDA 應用程式轉譯為OpenCL Device 可以執行之 Host Code 與 Device Code,藉此將 TensorFlow 原生之 CUDA 程式碼轉為 OpenCL Device Kernel,並為 OpenCL 設計一 StreamExecutor 而獨立為一 TensorFlow 分支 TF-Coriander。 
- 
-TensorFlow Stream Executor 為 Google 為 TensorFlow 定義出 Kernel API 的共用介面,並將與硬體相依的相關實作於各目標之 Stream Executor 中實現,其架構 
-如 Fig. 2 所示。 
-\\ 
-\\ 
-<<fig2>> 
-\\ 
-\\ 
-該架構概念上是以 Stream Executor 作為各目標平台的硬體抽象層,上方應用程式(Kernel API)會透過統一介面對虛擬裝置進行諸如記憶體分配、指令派發與Kernel Process Monitoring 等等資源管理相關命令;而各平台開發者也可藉此將平台相關優化程式放入 Kernel Implementation 中以優化各 Kernel 於該平台的執行效率。為了讓使用者可以使用 TensorFlow 原有的 API 在 CASLab GPU 上做人工智慧應用,CASLab 修改了 TensorFlow API 的後端實作內容如 Fig. 3 所示,實作了約三十多種 CNN 需求的 Operations 來支援跑在 AI 應用程式上。 
-\\ 
-\\ 
-<<fig3>> 
-\\ 
-\\ 
-==== OpenCL Runtime ==== 
-為了因應各種不同運算需求,現今的運算平台普遍由 CPU、GPU 或 ASIC 等異質性硬體所組成。而過去不同平台的應用程式開發者經常會需要重新設計應用程式/演算法與執行架構以配合 Device Vender 所提供的 Device Model 與 Device Driver,使得設計出的應用程式通常不具備可移植性。為此,Apple 提出一開源語言框架-Open Computing Language (OpenCL),並交由非營利組織 Khronos Group 進行管理、維護。OpenCL 為了讓使用者能有效的管理資源,設計了一套軟體架構,讓使用者能由上至下,由大到小的來管理硬體上的資源,如 Fig. 4 所示。CASLab GPU 為了能夠有效支援 OpenCL API,以 C++物件導向,設計一個符合規範的 OpenCLRuntime API,其中每一個物件內部會記錄與硬體相關的資訊以及使用者使用各項資源的情形。 
-\\ 
-\\ 
-<<fig4>> 
-\\ 
-\\ 
-CASLab 實作的 API 有四大類,目前共計 33 個,如 Fig. 5 所示 
-1. Platforms 相關 
-[1] Platform object 用以實作取得整個平台系統相關資訊的 API 
-[2] Device object 用以實作取得 Platform 中數個裝置資訊的 API 
-[3] Context object 用以管理使用者在一個 Device 需要的硬體資源 
-2. Programs 相關 
-[1] Program object 用來記錄使用者所撰寫的 Device code,內部可以含 
-有多個 kernel。編譯 Device code 的 API (clBuildProgram),需使用 
-此物件來實作,先呼叫 CASLab 所實作之 Compiler,完成編譯流程 
-後,將結果紀錄再次物件中。。 
-[2] Kernel object 
-此物件可記錄編譯完成後的 Program 中的其中一個 kernel,並且用以 
-記錄要派發給 GPGPU 的相關資訊。 
-3. Memory 相關 
-[1] Memory object 
-用來宣告硬體空間給使用者,並且使用者也能用此類別中的相關 API, 
-來讀取或寫入資料到 GPGPU。 
-4. Command queues 
-[1] Command queues object 
-用來管理使用者所要派發給 GPGPU 的工作資訊,內部紀錄使用者要派 
-發的順序與內容。 
-\\ 
-\\ 
-<<fig5>> 
-\\ 
-\\ 
-==== HSA runtime ==== 
-類似於 OpenCL 提供一共同的平行運算軟體開發 Framework,HSA 其旨為提供一共同硬體介面。不同於 OpenCL 規範了統一的應用程式開發介面,HSA 規範了統一的硬體操作介面,以簡化上層如 OpenCL 等與底層進行橋接介面之開發複雜度。HSA主要定訂了 Master Device (E.g. CPU) 與 Slave Device (E.g. GPU) 之間的記憶體空間擺放格式、資料傳輸方式與指令傳送方式等基本溝通協定。並定義一共用中介語言HSAIL (Heterogeneous System Architecture Intermediate Language) 供軟體層使用,使高階語言如 OpenCL Kernel Code Compiler 設計商不需要針對不同目標硬體額外開發一套編譯器,僅需於 Kernel 派發時由裝置定義之 Finalizer 將 HSAIL 轉譯至目標可執行檔。舉例來說,HSA 與 OpenCL 進行整合時 OpenCL Kernel Code 轉至 HSAIL 之編譯器可為採用 AMD CLOC,而目標硬體為 CASLab GPU 時再透過我們實驗室先前所開發之 Finalizer 將 HSAIL 進行指令擴充、對應並編譯為 CASLab GPU 所支援之可執行檔。但這套流程在實際執行上的效能並不佳,因為編譯器採用的是 AMD CLOC 在 
-許多時候並不能針對目標硬體去優化,因此 CASLab GPU 是採用 HSA + LLVM Compiler 來達到編譯執行檔的優化。 
-CASLab 實作之 HSA runtime 如 Fig. 6 所示,HSA API 可分成四大類,與 OpenCL API 相互對應。 
-1. Agent 相關,與 OpenCL API 中 Platforms 對應,用以取得硬體相關資訊。 
-2. Program 相關,此部分直接呼叫 CASLab OpenCL Compiler 來將使用者的 Device code 編譯成 GPU 執行檔。 
-3. Memory 相關,與 OpenCL API 中的 Memory object 對應,為 OpenCL 
-API 中所需要的 GPU 記憶體做管理。 
-4. Queues and Signals 相關,與 OpenCL API 的 Command Queue 對應, 
-可將 OpenCL API 中所發出的工作,轉換成信號通知 GPU 來執行。 
-\\ 
-\\ 
-<<fig6>> 
-\\ 
-\\ 
-==== LLVM Compiler ==== 
-LLVM 全名為 Low Level Virtual Machine,由 Vikram Adve 與 Chris Lattner 進行開發。LLVM 起源為針對動態與靜態編譯研究所設計的開發環境/虛擬機器,提供數種開發與分析工具搭配直譯器/虛擬平台以執行目標程式;隨著專案開發越來越豐富,LLVM 發展方向也逐漸由虛擬平台轉變為編譯器開發框架,專案名稱內的 Virtual Machine 也不再代表虛擬機開發,使目前 LLVM 專案名稱僅以代表整體開發、不再具備原先專案意義。也由於 LLVM 逐漸轉向 Compiler 開發框架,開始越來越多公司轉向支持/採用 LLVM 作為其硬體 Compiler 之開發環境,如 Apple 於 2005 年開始大 
-力支持 LLVM,且採用 LLVM 平台作為其作業系統之預設編譯環境提供使用者使用。 
-\\ 
-\\ 
-<<fig7>> 
-\\ 
-\\ 
-\\ 
-普遍編譯器設計上會依工作內容進行分工,將整體編譯流程拆分為 Compiler Front-End、Optimizer 與 Backend 這三部分元件,其編譯流程如 Fig. 7 所示。其個別功能為:Front-End-負責進行與語言相關的處理;例如,將由 C++所設計之程式碼進行轉譯、轉譯為內部所需的 AST Tree 等語法樹資料結構,並執行語言前處理相關步驟。Optimizer 則為程式碼內容相關的優化步驟;例如,常數前處理、條件式優化等等與語言相依的優化處理。Backend 則將前兩部分所產生的資料結構進行指令統整,並產生出目標可執行的指令、檔案格式。 
- 
-為了於 LLVM Infrastructure 中新增 CASLab GPU 目標硬體支援,需要 LLVM Project 內的” lib/Target”目錄中新增本實驗室設計之硬體平台-CASLab GPU,為方便使用,將名稱簡化為 CASGPU。CASLab GPU Target Machine 於 LLVM Project內的模組架構如 Fig. 8 所示。 
- 
-我們需要先建構出硬體的命名空間-CASGPU,並於該命名空間內建立各項子模組與功能等平台內需使用之相關功能。CASGPU 作為 CASLab GPU 硬體於 LLVM 中的 Target Machine,用以表示諸如 X86、ARM 與 RISC-V 等不同目標硬體架構。另外,在 CASGPU Target Machine 下,另外新增了一名為 HSA SubTarget,用以代表在 CASGPU 目標平台下採用 HSAIL-lite 指令格式的目標架構,並依據 HSAIL 之規範於此定義共用之參數與功能;例如,Memory Space 與 Calling Convention 等。最後,定義一目標晶片(C100-CASLab-GPU ISA V1.0.0),以代號”CA”作為硬體代表並作為各設計檔案命名前綴,於內部定義暫存器數量、指令支援等硬體相依之功能。 
-\\ 
-\\ 
-<<fig8>> 
-\\ 
-\\ 
-\\ 
-在說明完 LLVM Compiler 在 CASLab GPU 是如何規劃後,實作上我們的編譯器目前包含了大約 15000 行的Ccode。 
- 
-Fig. 9 顯示 CASLab GPU 編譯器與 CUDA 的系統對照圖。圖中最上層的是輸入資料的格式, CUDA 要求輸入 CUDA 格式的 .cu 檔案,其他兩者為 CASLab 支援OpenCL 的 .cl 檔案。而第二層則是三者分別使用的不同編譯器,原版的 CASLab GPU 是採用 AMD CLOC + Finalizer 方案,但因為 AMD CLOC 只提供 Binary 使用,而必須符合其架構設計出對應的 Finalizer 導致許多優化無法達到,新版的CASLab GPU 設計了自己的 OpenCL LLVM Compiler,使平台更有彈性,也達到效能上的優化。 
-\\ 
-\\ 
-<<fig9>> 
-\\ 
-\\ 
-\\ 
- 
-==== CASLab GPU 硬體架構與設計 ==== 
- 
-CASLab GPU 為一 SIMT (Single Instruction Multiple Thread)架構,如 Fig.10 所示,主要由 Interconnection Network (IN)、多個 SM (Streaming Multiprocessor)、WS (Workgroup Scheduler)所組成。IN 負責連接外部 DRAM 和各個元件之間以及資料的搬運。SM 則是運算與執行的主要核心單元,WS 為 GPU 內部之總控制器,主要負責與 CPU 溝通、接收來自 CPU 的工作以及派發Workgroup。 
- 
-GPU 執行緒的排程會經由兩層不同的排程單元來派發執行緒,第一排程器Workgroup Scheduler。當 CPU 發送新的工作時,以 Grid 為單位接收所要執行之程式,再進行切割與排程後,以 Workgroup 為單位派發至每個 SM 去做執行。SM 在收到 Workgroup 後,會根據 SIMD width 分成多個 Warp,並以 Warp 為單位進行運算,同一個 Warp 內的執行緒為平行運算。第二排程器為位於 SM 內部 Front-end 的 Warp Scheduler,將多個 Warp 進行排程後,交由 Back-end 運算單元處理。 
-\\ 
-\\ 
-<<fig10>> 
-\\ 
-\\ 
-\\ 
-CASLab GPU 的 SM 架構如 Fig. 11 所示,可分為 Workgroup Initializer、Front-end Pipeline 和 Back-end Pipeline 三部分。Workgroup Initializer 負責接收Workgroup 以及其初始化,Front-end 主要為 Warp 之排程以及指令的前處理與Decode,Back-end 則負責資料的運算以及 Load/Store 之相關。 
- 
-下面章節會分別對 Workgroup Initializer、Warp Scheduler、Divergence 
-Stack 這三個對 GPGPU 極為重要的模組做介紹。 
-\\ 
-\\ 
-<<fig11>> 
-\\ 
-\\ 
-\\ 
-==== Workgroup Initializer ==== 
-==== Warp Scheduler ==== 
-==== Divergence Stack ==== 
- 
-\\ 
-===== 設計驗證結果與效能評估 ===== 
-==== 實驗環境 ==== 
-==== 測試程式 ==== 
-==== CASLab LLVM Compiler 效能結果 ==== 
-==== CASLab GPUsim 效能結果 ==== 
-==== FPGA 驗證成果 ==== 
- 
-\\ 
-===== 附錄 =====  
  
group/aionchip.1591172080.txt.gz · 上一次變更: 2020/06/03 08:14 由 admin