張立志 趙士彭 章隆兵

(*計算機體系結(jié)構(gòu)國家重點實驗室(中國科學(xué)院計算技術(shù)研究所) 北京 100190)

(**中國科學(xué)院計算技術(shù)研究所 北京 100190)

(***中國科學(xué)院大學(xué) 北京 100049)

0 引言

隨著個人電腦與智能手機的普及[1],人們對細膩逼真的3D 圖形繪制需求愈發(fā)強烈。圖形處理器(graphics processing unit,GPU)作為處理3D 圖形任務(wù)的專用芯片,其研究與發(fā)展對提升圖形應(yīng)用繪制效果有重要意義。

現(xiàn)有的典型GPU 架構(gòu)有Fermi 架構(gòu)[2]與graphics cone next (GCN)架構(gòu)[3]。Fermi 架構(gòu)是Nvidia公司于2008 年提出,該架構(gòu)將頂點著色處理模塊與像素著色處理模塊合并為基于流處理器的統(tǒng)一渲染模塊,統(tǒng)一渲染架構(gòu)的流處理器與專用集成電路(application-specific integrated circuit,ASIC)實現(xiàn)的固定圖形算法[4-7]處理電路共同實現(xiàn)整個圖形處理流水線。GCN 架構(gòu)由超威半導(dǎo)體公司于2012 年提出,該架構(gòu)將原本使用的VLIW+SIMD 改進為SIMT架構(gòu)。但因為商業(yè)原因,Nvidia 與AMD 公司并沒有披露這兩款架構(gòu)的設(shè)計細節(jié),導(dǎo)致研究者無法直接使用這些架構(gòu)進行GPU 研究。

學(xué)術(shù)界對GPU 的研究主要集中在通用計算領(lǐng)域,例如gpgpu-sim[8]、gem5-gpu[9-10]、multi2sim[11]、MIAOW[12]、Accel-Sim[13],通用計算只涉及到GPU的流處理器模塊,并不涉及ASIC 模塊,這些研究對GPU 硬件與應(yīng)用行為的分析更多地集中在流處理器與cache 模塊,并沒有對圖形應(yīng)用基礎(chǔ)的圖形算法模塊進行研究分析。

學(xué)術(shù)界完整實現(xiàn)GPU 流處理器模塊與ASIC 固定圖形算法模塊的典型GPU 架構(gòu)有ATTILA[14]與Emerald[15]。ATTILA 是2006 年提出的一款GPU 架構(gòu),該架構(gòu)使用高級語言模擬器實現(xiàn)了完整的周期精確模擬,但其很多設(shè)計已經(jīng)不符合現(xiàn)代GPU 架構(gòu)。Emerald 由英屬哥倫比亞大學(xué)于2019 年提出,在gpgpu-sim 模擬器中增加了圖形算法模塊的實現(xiàn)。但Emerald 并沒有對圖形算法模塊實現(xiàn)周期精確的模擬。ATTILA 與Emerald 的另一個不足是缺少RTL 實現(xiàn),導(dǎo)致其分析結(jié)果不夠準(zhǔn)確。

統(tǒng)觀學(xué)術(shù)界和工業(yè)界現(xiàn)有的GPU 平臺,有的封鎖實現(xiàn)方法,有的使用古老的GPU 架構(gòu),有的只使用高級語言模擬。GPU 研究領(lǐng)域缺少一款開放實現(xiàn)方法、使用現(xiàn)代GPU 架構(gòu)并且進行寄存器傳輸級(register-transfer level,RTL)實現(xiàn)的GPU 研究平臺。

本文主要貢獻為實現(xiàn)了一個包含完整圖形功能的RTL 級的GPU 研究平臺GPU-Hi,解決了上述問題。并使用28 nm 工藝完成物理設(shè)計,該平臺支持OpenGL 2.0 框架,使用ASIC 電路實現(xiàn)固定圖形算法模塊,使用SIMT 流處理器實現(xiàn)統(tǒng)一著色渲染模塊。在實驗?zāi)K本文基于該平臺對glmark2[16]測試集進行了應(yīng)用行為分析并對GPU 進行硬件效率分析。結(jié)果證明,圖形應(yīng)用程序在進行分辨率提升時,圖形任務(wù)負載不會等比例增加;硬件光柵化模塊的真實性能受到著色程序執(zhí)行效率與訪存效率的影響,單一提升GPU 部分模塊硬件配置,GPU 整體性能并不會明顯提升。這些結(jié)論對圖形應(yīng)用開發(fā)人員與GPU 結(jié)構(gòu)設(shè)計人員有借鑒意義。

本文包含以下幾個部分。第1 節(jié)介紹了3D 圖形應(yīng)用背景與GPU 架構(gòu)背景;第2 節(jié)描述了GPUHi 的RTL 實現(xiàn)方法;第3 節(jié)分析了圖形應(yīng)用計算特性;第4 節(jié)展示了GPU-Hi 的RTL 實現(xiàn)的參數(shù),并使用glmark2 測試集進行圖形應(yīng)用行為分析與GPU 硬件效率分析;第5 節(jié)提出未來研究工作并對本文進行總結(jié)。

1 背景介紹

1.1 3D 圖形應(yīng)用背景

目前主流3D 圖形應(yīng)用程序主要使用Open-GL[17]與DirectX[18-19]2 個圖形庫進行實現(xiàn)。OpenGL圖形庫是一個面向2D 與3D 計算機圖形學(xué)的跨平臺語言的應(yīng)用程序庫,1991 年由SGI 公司提出,后來由Khronos 組織進行版本更新與維護。DirectX 圖形庫由微軟公司提出,實現(xiàn)內(nèi)容與OpenGL 圖形庫類似。

這2 個圖形庫都為3D 圖形程序定義了一條圖形處理流水線,這2 條流水線處理流程基本相同。圖形處理流水線將處理流程分為頂點著色階段、光柵化階段、像素著色階段、后片段處理階段。頂點著色階段以頂點數(shù)據(jù)為處理對象,對每一個頂點數(shù)據(jù)使用頂點著色程序進行頂點的位置計算與屬性計算。光柵化階段將經(jīng)過計算的頂點數(shù)據(jù)組織成以三角形為代表的基本圖元,并以這些基本圖元為處理對象,將圖元轉(zhuǎn)換生成屏幕像素點。像素著色階段以像素點為基本處理單元,對每一個像素點使用像素著色程序進行像素點的顏色計算。OpenGL 圖形庫使用高級著色器語言(high-level shading language,HLSL)[20]實現(xiàn)頂點著色器程序與像素點著色器程序,DirectX 圖形庫則使用GLSL 語言[21]進行實現(xiàn)。后片段處理階段將經(jīng)過著色的像素點數(shù)據(jù)進行深度剔除或透明混合操作,處理過后的像素點最終組成在屏幕中顯示的圖像。

1.2 GPU 架構(gòu)背景

GPU 是針對3D 圖形應(yīng)用程序而設(shè)計的應(yīng)用加速芯片。依據(jù)OpenGL 與DirectX 圖形庫所定義的圖形處理流水線,同時為增強自身處理能力,GPU將自身架構(gòu)設(shè)計為統(tǒng)一渲染架構(gòu)。因為頂點著色階段與片段著色階段都使用著色程序進行計算,所以統(tǒng)一渲染架構(gòu)使用同一塊流處理器實現(xiàn)這兩階段的處理?；谶@兩個階段所具有的并行特性,流處理器使用單指令多線程(single instruction multiple threads,SIMT)架構(gòu)。根據(jù)光柵化單元與后片段處理階段的流式數(shù)據(jù)處理特性,使用ASIC 電路對其進行實現(xiàn)。

2 GPU-Hi 的RTL 實現(xiàn)方法

2.1 GPU-Hi 簡介

GPU-Hi 使用本文作者所設(shè)計的一款GPU 架構(gòu)進行RTL 實現(xiàn),該GPU 架構(gòu)已經(jīng)通過高級語言模擬器[22-23]完成了正確性驗證。GPU-Hi 支持Open-GL 2.0 渲染框架,流處理器實現(xiàn)為統(tǒng)一渲染架構(gòu),各個處理單元支持靈活擴展。本文介紹了GPU-Hi的RTL 實現(xiàn)方法,并使用GPU-Hi 進行圖形應(yīng)用行為分析與GPU 硬件性能分析。

GPU-Hi 包括5 個部分,即命令處理器(command processor,CP)、全局任務(wù)調(diào)度器(global task scheduler,GTS)、圖形處理集群(graphics processing cluster,GPC)、二級緩存(level 2 cache,L2 Cache)和內(nèi)存控制器(memory controller,MC)。其中圖形處理集群包括6 個模塊,即計算處理引擎(compute engine,CE)、幾何處理引擎(geometry engine,GE)、圖元處理引擎(primitive engine,PE)、局部任務(wù)調(diào)度器(local task scheduler,LTS)、流處理器集群(stream processor cluster,SPC) 和輸出合并單元(output merge unit,OMU)。

GPU-Hi 結(jié)構(gòu)如圖1 所示。

圖1 GPU-Hi 架構(gòu)圖

本節(jié)后續(xù)部分介紹各模塊的具體實現(xiàn)方法。

2.2 命令處理器

命令處理器是GPU 的整體控制模塊,本平臺通過在命令處理器模塊嵌入一個GS132 處理器核進行實現(xiàn)。該處理器核解析來自主機中央處理器(central processing unit,CPU)的圖形繪制命令與繪制任務(wù)參數(shù),針對不同的繪制命令與任務(wù)參數(shù)配置全局任務(wù)調(diào)度器和圖形處理集群。在GPU 流水線完成任務(wù)的繪制后,命令處理器把繪制結(jié)束信息通知給顯示輸出模塊,最終由顯示輸出模塊將結(jié)果數(shù)據(jù)輸出在顯示器屏幕上。

2.3 全局任務(wù)調(diào)度器

全局任務(wù)調(diào)度器從命令處理器接受繪制命令,并根據(jù)調(diào)度算法將繪制命令分配到對應(yīng)的圖形處理集群中。

2.4 圖形處理集群

圖形處理集群是GPU-Hi 的核心處理模塊。包括幾何處理引擎、圖元處理引擎、流處理器集群、局部任務(wù)調(diào)度器、輸出合并單元。

幾何處理引擎主要包括頂點索引數(shù)據(jù)拆分模塊與頂點著色任務(wù)重定序隊列。頂點索引拆分模塊使用硬件電路實現(xiàn),解析命令處理發(fā)送來的命令參數(shù),獲得頂點數(shù)據(jù)索引,將頂點數(shù)據(jù)索引組織為頂點著色任務(wù),并將著色任務(wù)發(fā)送至局部任務(wù)調(diào)度器。著色任務(wù)包括著色程序的指令地址、數(shù)據(jù)地址、寄存器信息。頂點著色任務(wù)重定序隊列由隨機存取存儲器(random access memory,RAM)實現(xiàn),保存著色器任務(wù)的結(jié)果數(shù)據(jù),并按照著色器任務(wù)生成順序?qū)⒔Y(jié)果數(shù)據(jù)發(fā)送到圖元處理引擎。

圖元處理引擎主要包括固定的光柵化算法模塊、像素著色任務(wù)生成模塊和像素著色任務(wù)重定序模塊。固定光柵化算法模塊實現(xiàn)了3D 圖形光柵化算法。區(qū)別于通用CPU 對數(shù)值處理的定點、單精度、雙精度數(shù)值格式,該模塊使用大量定制的運算單元提高運算效率與數(shù)值精度。這些定制的運算單元包括單精度數(shù)據(jù)處理、可變精度數(shù)據(jù)處理、定點數(shù)據(jù)處理、多數(shù)據(jù)融合運算處理等。像素著色器任務(wù)生成模塊將固定光柵化算法模塊生成的像素數(shù)據(jù)組織為像素著色任務(wù),并為像素著色任務(wù)提供指令地址與預(yù)賦值的寄存器數(shù)據(jù)。像素著色任務(wù)重定序隊列由RAM 實現(xiàn),保存頂點著色任務(wù)的結(jié)果數(shù)據(jù),并且按照像素著色任務(wù)生成順序?qū)⑾袼刂蝿?wù)結(jié)果數(shù)據(jù)發(fā)送給輸出合并單元。

流處理器集群由多個流處理器模塊構(gòu)成。流處理器模塊使用順序流水線的單指令多線程(SIMT)架構(gòu),每周期可以發(fā)射一條指令,這條指令可以同時驅(qū)動多個線程進行數(shù)據(jù)的讀寫與運算。流處理器模塊包括融合乘加運算單元、超越函數(shù)單元、紋理單元、便箋式存儲單元、L1 Cache 單元和寄存器單元。融合乘加單元可以執(zhí)行融合乘加運算;超越函數(shù)單元可以執(zhí)行正弦、倒數(shù)、指數(shù)、開平方等運算;紋理單元通過紋理指令來獲取紋理數(shù)據(jù)的地址,并通過L1 Cache 讀取紋理數(shù)據(jù),并且對讀取得到的紋理數(shù)據(jù)進行濾波操作;便箋式存儲單元可以通過獨立尋址的方式為各個運算單元提供數(shù)據(jù),減小片外訪存壓力;L1 Cache 為模塊內(nèi)各運算單元提供數(shù)據(jù)。寄存器單元是各運算模塊最基礎(chǔ)的數(shù)據(jù)存儲單元,流處理器設(shè)計為所有運算單元無法直接從內(nèi)存進行數(shù)據(jù)讀寫,讀取數(shù)據(jù)時必須先將數(shù)據(jù)從內(nèi)存load 進寄存器,寫入數(shù)據(jù)時必須先將數(shù)據(jù)寫入寄存器。流處理器分別從幾何處理引擎與圖元處理引擎接收頂點著色任務(wù)與像素著色任務(wù),并將處理結(jié)果分別返回給幾何處理引擎與圖元處理引擎。

局部任務(wù)調(diào)度器用于保存流處理器模塊的資源分配與占用情況,并根據(jù)資源占用情況將接收到的頂點著色任務(wù)與像素著色任務(wù)分配調(diào)度至流處理器模塊。

輸出合并模塊主要包括深度測試與透明混合模塊。這兩個模塊使用定制的乘加運算單元實現(xiàn),將從圖元處理引擎接收的像素點數(shù)據(jù)直接進行計算處理,并輸出至片外幀緩沖區(qū),供顯示輸出模塊使用。

2.5 二級緩存模塊

片上二級緩存使用一個靜態(tài)RAM(static RAM,SRAM)實現(xiàn),用于處理流處理器集群中的L1 Cache的訪存請求,使用最近最少使用替換策略,在發(fā)生訪存地址缺失后,通過一個crossbar 將缺失的訪存請求發(fā)送至內(nèi)存控制器進行處理。

2.6 內(nèi)存控制器

內(nèi)存控制器負責(zé)與片外顯存交互,將L2 Cache的Miss 的訪存請求通過總線協(xié)議(advanced extensible interface,AXI)發(fā)送到片外顯存進行數(shù)據(jù)讀寫訪問。

3 圖形應(yīng)用計算特性分析

如1.1 節(jié)所述,圖形處理流水線的各個階段分別使用不同的數(shù)據(jù)對象作為最小處理單元,這便導(dǎo)致流水線各部分極易產(chǎn)生工作負載不均衡的問題。在早期GPU 中,頂點著色階段與像素著色階段分別由不同的GPU 硬件模塊進行處理,但因為頂點著色任務(wù)與像素著色任務(wù)的工作任務(wù)負載并不相同,很容易出現(xiàn)頂點著色任務(wù)過多或者像素著色任務(wù)過多的問題,這種負載不均衡問題嚴(yán)重影響了GPU 的工作效率。現(xiàn)代GPU 通過統(tǒng)一渲染架構(gòu)來解決這種問題,即使用統(tǒng)一的流處理器架構(gòu)同時處理頂點著色任務(wù)與像素著色任務(wù)。但統(tǒng)一渲染架構(gòu)只能解決著色器任務(wù)的負載不均衡,無法解決光柵化階段與著色器任務(wù)的負載不均衡問題。本節(jié)將對這一問題進行分析。

圖形處理工作分為需要順序執(zhí)行的3 個階段,即頂點著色階段、光柵化階段和像素點著色階段。

頂點著色階段對當(dāng)前任務(wù)中所有頂點數(shù)據(jù)執(zhí)行頂點著色程序,頂點著色任務(wù)的工作負載與當(dāng)前任務(wù)中頂點數(shù)目與頂點著色程序復(fù)雜度呈正相關(guān)。

光柵化階段分為以下幾個步驟。步驟1 將頂點數(shù)據(jù)組織成為圖元數(shù)據(jù);步驟2 將圖元數(shù)據(jù)生成以4×4 pixel 組成的frag(如圖2);步驟3 逐個處理frag 數(shù)據(jù),確定該frag 是否存在覆蓋圖元的quad 數(shù)據(jù),并計算這些quad 與pixel 的屬性數(shù)據(jù)。步驟1以頂點數(shù)據(jù)為對象,每周期讀取一個頂點數(shù)據(jù),其工作負載由頂點著色階段傳遞來的頂點數(shù)目決定;步驟2 與步驟3 以frag數(shù)據(jù)為處理對象,每周期處理一個frag 數(shù)據(jù),其工作負載由多個因素影響,包括每個頂點的位置信息、繪制任務(wù)所配置的屏幕分辨率信息。

圖2 frag 結(jié)構(gòu)示意

像素點著色階段需要將所有輸入來的quad(如圖2)數(shù)據(jù)進行像素點著色程序處理。則像素點著色階段的工作負載依賴于像素著色程序的指令復(fù)雜度,同時依賴于光珊化階段第3 步生成的quad 數(shù)據(jù)數(shù)目。

通過對圖形處理工作各階段任務(wù)的分析,可以得出結(jié)論,圖形處理工作在各個階段,甚至是同一階段的不同步驟,都有著不同的任務(wù)復(fù)雜度。同時由于頂點著色階段、光珊化階段和像素著色階段需要順序執(zhí)行,任務(wù)復(fù)雜度不同會導(dǎo)致圖形處理負載不均衡。例如,當(dāng)頂點著色任務(wù)負載過重,則會出現(xiàn)光柵化階段輸入數(shù)據(jù)供給過慢的問題;當(dāng)像素著色階段處理過重,則會出現(xiàn)光柵化階段結(jié)果數(shù)據(jù)輸出被堵塞的問題。各個階段的任務(wù)負載又依賴于頂點位置與屏幕分辨率等應(yīng)用行為,而硬件芯片在設(shè)計完成后各模塊的處理能力又無法變化,所以各模塊的處理效率將極大地受到圖形處理各階段的工作負載影響,即硬件模塊的執(zhí)行效率受到圖形應(yīng)用行為的影響。

4 平臺實現(xiàn)及實驗分析

本節(jié)首先介紹GPU-Hi 平臺的硬件實現(xiàn)情況,而后基于本平臺進行了2 組實驗分析。

兩組實驗分別為:實驗1 為圖形應(yīng)用程序在配置為不同分辨率時,圖形應(yīng)用工作負載的變化;實驗2為流處理器與內(nèi)存控制器配置為不同規(guī)模時,GPU 光柵化模塊的性能變化。GPU 作為3D 圖形應(yīng)用加速器,圖形應(yīng)用的工作負載直接影響GPU 各硬件模塊的計算效率。

4.1 GPU-Hi 物理設(shè)計結(jié)果

本文使用28 nm 工藝對該平臺進行物理設(shè)計,在目標(biāo)主頻為500 MHz 的情況下,芯片總面積為7.90 μm2,主要模塊實際面積開銷如表1 所示。

表1 GPU-Hi 在28 nm 下面積開銷

4.2 分辨率對圖形任務(wù)負載影響

本文選取glmark2 測試集中build-horse 進行實驗分析。glmark2 是一款OpenGL 應(yīng)用程序接口(application programming interface,API)程序測試集。build 測試是一個在頂點著色階段進行光照渲染的圖形程序。

首先通過將分辨率配置為400×300、600×450、800×600、1000×750、1200×900,來展示分辨率對圖形應(yīng)用行為的影響。

由于頂點數(shù)目屬于圖形任務(wù)固有屬性,不隨分辨率變化,所以頂點著色階段的任務(wù)負載不隨分辨率變化。但圖元數(shù)據(jù)所生成的frag 數(shù)目屬于圖形任務(wù)動態(tài)屬性,與分辨率相關(guān),即光珊化任務(wù)負載會隨分辨率變化。

圖3 展示了build-horse 程序在不同分辨率下光珊化階段中frag 數(shù)量與frag_visi 數(shù)量的統(tǒng)計信息。其中frag 數(shù)量是指需要進行像素點遍歷處理的frag數(shù)據(jù)數(shù)目,代表了光柵化階段的工作負載情況;frag_visi 數(shù)量是指經(jīng)過像素點遍歷處理后,被標(biāo)記為可見的frag 數(shù)目,代表了有效的frag 數(shù)據(jù);光珊化有效率是frag_visi 數(shù)量與frag 數(shù)量的比值。從圖中可知,雖然frag 數(shù)量與frag_visi 數(shù)量均隨分辨率提高而提高,但兩數(shù)量的比值,即光柵化有效率最終也隨分辨率提高而提高。

圖4 展示了build-horse 程序在不同分辨率下光柵化階段中quad 數(shù)量與pixel 數(shù)量的統(tǒng)計信息。其中quad 數(shù)量是指存在可見像素點的quad 數(shù)據(jù)數(shù)目,代表了像素著色階段的工作負載;pixel 數(shù)量表示真正可見像素點的數(shù)量,代表了圖形應(yīng)用真正需要計算的像素數(shù)目。由圖2 可知,1 個quad 數(shù)據(jù)對應(yīng)4 個pixel 數(shù)據(jù),所以像素著色有效率是pixel 數(shù)量與4 倍quad 數(shù)量的比值。從圖中可知,quad 數(shù)量與pixel 數(shù)量均隨分辨率提高而提高,同時像素著色有效率也隨分辨率提高而提高。

由圖3 和圖4 可知,隨著分辨率的提高,光柵化有效率與像素著色有效率都隨之提高,這是因為在提升分辨率以后,相同屏幕面積下,每一個像素點所占屏幕面積更小,圖形應(yīng)用的3D 模型建模更加細膩,每一個三角形覆蓋的誤差區(qū)域也就更小。

圖4 quad 與pixel 數(shù)據(jù)變化

圖5 展示了在分辨率增大后,以400×300 分辨率為基準(zhǔn),各項數(shù)據(jù)的比例情況,其中代表pixel 的線與代表像素的線完全重合。圖中像素表示當(dāng)前分辨率下屏幕中的像素數(shù)目,例如400×300 分辨率中像素數(shù)目為120 000。frag、quad、pixel 數(shù)據(jù)意義與圖3、圖4 相同?？梢钥闯?在分辨率增大后,所有數(shù)據(jù)量都隨之增大,但各個數(shù)據(jù)增大的比例并不相同。代表光柵化任務(wù)負載的frag 數(shù)據(jù)小于代表像素著色任務(wù)負載的quad 數(shù)據(jù)變化趨勢,同時兩者變化趨勢均明顯小于像素個數(shù)的變化趨勢。

對圖3～圖5 的分析可以得出以下結(jié)論:(1)在圖形任務(wù)分辨率提升時,分辨率模塊與像素著色模塊的工作有效率均有明顯提升;(2)在對圖像分辨率進行提高時,即提升畫質(zhì)時,各項工作負載并不會隨分辨率的變化而等比例變化;(3)在圖形任務(wù)分辨率提升時,GPU 各處理模塊的任務(wù)負載變化比例并不相同,即GPU 各處理模塊會產(chǎn)生負載不均衡問題。

圖5 光柵化各項數(shù)據(jù)變化比例

4.3 硬件配置對光珊化模塊利用率影響

如第2 節(jié)對GPU 硬件結(jié)構(gòu)描述,光柵化模塊負責(zé)將圖元數(shù)據(jù)生成為像素點數(shù)據(jù),它并不執(zhí)行著色器指令,也不進行顯存的讀寫操作,指令執(zhí)行能力與顯存讀寫能力不會直接影響光柵化的效率。但是GPU 硬件使用順序的硬件流水線實現(xiàn)圖形處理算法,所以在執(zhí)行圖形任務(wù)時,GPU 各個硬件模塊的執(zhí)行時間是相同的,即光柵化模塊的處理效率會受到流處理器能力與訪存能力的間接影響。這里對這一問題進行實驗分析。

表2 展示了應(yīng)用程序在配置為不同分辨率時,光柵化模塊的處理效率變化情況。total_time列表示GPU-Hi 的光柵化模塊執(zhí)行當(dāng)前任務(wù)所執(zhí)行的總周期數(shù),frag_num表示對應(yīng)分辨率下光柵化執(zhí)行的frag 數(shù)據(jù)數(shù)目,ra_rate表示光柵化模塊處理frag的速率,例如第一行表示分辨率為400×300 時,GPU-Hi 的光柵化模塊執(zhí)行了56 239 周期,處理了23 395 個frag 數(shù)據(jù),平均每周期處理0.415 個frag數(shù)據(jù)。根據(jù)表2 可以看出,在分辨率與光柵化工作負載發(fā)生變化時,光柵化速率并沒有發(fā)生顯著改變,并且光柵化效率均不高,距離理想狀態(tài)下的每周期處理1 個frag 數(shù)據(jù)的差距很大。這表示光柵化模塊并不是GPU-Hi 的性能瓶頸,處理速率過低的原因可能是因為流處理器集群的處理能力不足,例如頂點著色階段處理頂點數(shù)據(jù)的速度過慢,導(dǎo)致光柵化模塊接收輸入數(shù)據(jù)的速率太慢;像素著色階段處理像素點數(shù)據(jù)過慢,導(dǎo)致光柵化模塊生成的frag 數(shù)據(jù)無法向后級流水線傳遞。

表2 分辨率與光柵化速率統(tǒng)計

為分析光柵化速率過慢的原因,本文對GPU 硬件中流處理器集群與ram 的配置進行更改。流處理器集群配置包括1 sp 和2 sp,其中1 sp 表示GPU-Hi中原本的流處理器集群架構(gòu),即整個GPU-Hi 只有一個流處理器模塊,所有的頂點著色任務(wù)與像素著色任務(wù)均使用這一組流處理器進行處理;2 sp 作為對照組,表示使用2 組流處理器模塊來完成頂點著色任務(wù)與像素著色任務(wù),可大幅提高著色任務(wù)處理能力。ram 配置包括small ram 和super ram,其中small ram 表示GPU-Hi 中原本的ram 架構(gòu),即整個GPU-Hi 只有一個ram 進行顯存讀寫處理,所有需要顯存操作的模塊均共享該模塊;super ram 架構(gòu)作為對照組,表示為GPU-Hi 中所有需要進行顯存讀寫的模塊均配備獨立的訪存處理單元,可以大幅提升整個GPU-Hi 的訪存能力。

在實驗中,對每個分辨率進行4 組對照實驗:實驗組1 為1 sp、small ram;對照組2 為1 sp、super ram;對照組3 為2 sp、small ram;對照組4 為2 sp、super ram。4 組對照實驗的結(jié)果如圖6 和圖7 所示。

圖6 任務(wù)執(zhí)行總時間隨硬件配置變化圖

圖7 光柵化速率隨硬件配置變化圖

由圖可知,在5 種分辨率下,1 sp 與small ram均表現(xiàn)出最慢的光柵化速率。

在不更改ram 而單純將1 sp 更改為2 sp 后,所有分辨率下frag 處理能力都發(fā)生了明顯提升,每周期處理數(shù)目分別提升了0.22、0.21、0.17、0.14、0.11,提升比例分別為53.4%、48.3%、40.4%、35.1%、29.1%。這說明1sp 與small ram 的配置下,流處理器集群的工作負載過重,其計算能力極大限制了流水線整體的處理效率,并且在分辨率越低的情況下,流處理器集群的計算能力對光柵化的限制越明顯,流處理器集群與光柵化模塊的負載不均衡問題也越明顯。但此時流處理器集群的理論計算能力增加了100%,光柵化能力雖然有提升,卻沒有進行等比例增加,最高提升比例僅有53%,最低提升比例僅僅為29%,這說明在2 sp 與small ram 的配置下,GPU的瓶頸可能是ram 的訪存能力,而不是流處理器集群的計算能力,下文將增加ram 配置的對比實驗。

在不更改流處理器集群配置而單純將small ram 更改為super ram 后,可以看出frag 的計算能力并沒有明顯的提升,5 種分辨率下光柵化每周期性能提升比例僅為5.1%、3.7%、6.3%、7.1%、7.8%,這說明在1 sp 的配置下,small ram 的處理能力已經(jīng)完全達到了工作負載的需求。

在將1 sp 更改為2 sp 同時將small ram 更改為super ram 后,相較于2 sp 與small ram 的配置,光柵化每周期性能提升比例分別為28%、28%、35%、38%、37%,可以看出此前2 sp 在配置small ram 時,流處理器集群的計算能力的確已經(jīng)滿足工作負載,但ram 的訪存能力無法滿足工作負載需求。對比1 sp與small ram 的配置,性能提升比例分別達到了97%、90%、90%、87%、77%。光柵化模塊的frag處理速度在600×450 分辨率時達到了最高的0.83 個/s frag 數(shù)據(jù),已經(jīng)接近1 個/s frag 的理論峰值。

根據(jù)以上分析可知,GPU 作為圖形應(yīng)用加速器,其內(nèi)部各個模塊分別使用ASIC 與SIMT 等不同架構(gòu)實現(xiàn),具有極強的異構(gòu)架構(gòu)特性。光柵化模塊作為流水線一部分,雖然不直接執(zhí)行著色器程序,也不進行訪存操作,但工作時的實時處理能力受到流處理器處理能力與訪存能力的影響。

5 結(jié)論

工業(yè)界因為商業(yè)問題無法提出一套完整的寄存器傳輸級GPU 研究平臺;學(xué)術(shù)界所使用的GPU 研究平臺中,MIAOW RTL 平臺沒有實現(xiàn)完整的圖形算法,而其他研究平臺如ATTILA、Emerald、Teapot,沒有通過RTL 實現(xiàn)。

在這一情況下,本文提出RTL 級的GPU-Hi 研究平臺,并描述了該平臺的硬件實現(xiàn)的方法。使用GS132 處理器核實現(xiàn)命令控制器,完成CPU 發(fā)送來的任務(wù)解析與整條流水線的調(diào)度配置;使用ASIC電路實現(xiàn)圖元處理引擎,完成復(fù)雜的3D 圖形光柵化算法;使用SIMT 架構(gòu)的流處理器實現(xiàn)流處理器集群,完成頂點著色程序與像素著色程序的執(zhí)行。

基于前述寄存器傳輸級GPU 研究平臺通過glmark2 測試集對3D 圖形應(yīng)用行為分析及GPU 硬件負載進行分析,得到以下結(jié)論。(1)圖形應(yīng)用的分析表明3D 圖形應(yīng)用的分辨率變化與分辨率所帶來的工作負載變化并不是等比例相關(guān),并且光柵化任務(wù)負載與著色器任務(wù)負載存在明顯的負載不均衡問題;(2)對GPU 硬件負載的分析表明,雖然光柵化模塊并不執(zhí)行著色器程序指令,也不直接進行顯存的讀寫操作,但其工作效率極大地受到流處理器與訪存能力的影響。

隨著人工智能的飛速發(fā)展,學(xué)術(shù)界越來越多的關(guān)注點投入到了GPU 在通用計算領(lǐng)域的研究,本文現(xiàn)有平臺的實現(xiàn)集中于GPU 在圖形渲染領(lǐng)域的研究,尚未實現(xiàn)通用計算功能。下一步的研究工作需要增加通用計算如OpenCL 的支持,同時需要進一步完善實驗平臺的工具鏈與調(diào)試環(huán)境,盡快將GPUHi 平臺開放給研究人員使用。