文獻標識碼: A
DOI:10.16157/j.issn.0258-7998.181708
中文引用格式: 馬城城,田澤,黎小玉,等. 統一渲染架構GPU圖形處理量化性能模型研究[J].電子技術應用,2019,45(2):27-32,36.
英文引用格式: Ma Chengcheng,Tian Ze,Li Xiaoyu,et al. Research on quantitative performance model of GPU graphics processing based on unified rendering architecture[J]. Application of Electronic Technique,2019,45(2):27-32,36.
0 引言
從1999年NVIDIA發布第一款GPU產品至今,GPU技術發展主要經歷了固定功能流水線階段、分離染色器架構階段、統一染色器架構階段[1]。其處理架構的不斷改變使得圖形處理能力和計算能力不斷提升,相應的流水線結構、并行計算結構、并行數據通信結構、存儲結構越發復雜,圖形處理性能指標已難以從單方面去設計、評價。研究GPU圖形處理性能模型意義重大。
國外NVIDIA、AMD等公司針對GPU圖形處理性能方面進行了大量研究,但都是各公司的核心機密,公開甚少[2]。國內在統一渲染架構GPU性能方面進行了一定理論探討,但主要集中在并行計算、存儲結構、編程優化方面,針對GPU設計本身的研究幾乎空白。
本文提出統一渲染架構GPU圖形處理量化性能模型,在分析統一渲染架構GPU并行架構和工作原理基礎上,分析影響圖形處理的各種因素:圖形指令生成、主機接口數據傳輸、圖形指令解析、圖形處理流水數據吞吐和統一染色陣列處理能力。為統一渲染架構GPU的性能參數設計提供方法支持。
1 統一渲染架構GPU圖形處理模型
圖形處理器經過近30年的發展,雖然圖形處理器體系結構、處理方式發生了巨大變化,但其基于Z-Buffer的光柵化圖形處理流水線一直沿用至今[3]。自2006年,NVIDIA發布統一渲染架構的GPU以來,統一渲染架構便成為GPU的主流[4]。NVIDIA、AMD等各廠家都有自己不同的實現方式,但基本的CPU+GPU異構工作方式、圖形處理流程都基本一致[5-6]。下文將在分析代表產品的基礎上,針對圖形處理性能抽象統一渲染架構GPU圖形處理模型。
1.1 GeForce 8800
GeForce 8800是2006年NVIDIA發布的第一款統一染色架構GPU,采用G80架構[7]。自此NVIDIA每兩年發布一款GPU架構。2006年發布G80,2008年發布Tesla-GT200,2010年發布Fermi-GF100,2012年發布kepler,2014年發布年Maxwell,2016年發布Pascal。每一款GPU架構都對染色陣列數量及結構進行優化、調整,但圖形處理過程改變甚微,基本保持著G80的處理過程,如圖1所示。
圖形處理任務由主機生成圖形指令存儲到主機內存中,GPU通過主機接口獲取圖形指令,然后將圖形指令解析為統一染色陣列和固定的硬件單元的控制和數據信息,配合完成圖形處理過程。
1.2 R700
R700是2008年AMD公司發布的具有大規模SIMD統一染色陣列的圖形處理器架構[6],結構如圖2所示。其存儲系統包括兩部分,一部分是駐于主機內存中的系統空間,另一部分則是位于GPU上的顯存空間。存儲系統中包含的數據包括命令隊列、指令、常數以及輸入、輸出流,其中命令隊列指明了GPU需要處理的任務;指令給出了執行部件的具體工作;常數、輸入和輸出流則提供了計算所需要的數據,這幾個部分要素構成了GPU運行的基本要素。
一個完整R700的應用分為兩個部分:運行在主機CPU上的主機程序和運行在GPU DPP陣列(Data-Parallel Processor,下文稱為染色陣列)上的kernel程序。應用在運行過程中主機程序生成染色陣列運行所需的數據、染色器程序及需執行的命令。GPU通過主機接口獲取主機生成的命令后由命令處理器(Command Processor)解析并控制固定處理單元和染色陣列運行,完成圖形處理。
1.3 統一渲染架構GPU圖形處理摸模型
抽象統一渲染架構GPU圖形處理過程,如圖3所示,包括主機指令生成、主機接口數據傳輸、圖形指令解析、固定圖形流水單元處理和統一染色陣列處理。主機和GPU通過“生產-消費者”關系工作,圖形指令是主機和GPU交互的“橋梁”,主機圖形指令生成負責圖形API運行時生成圖形指令,存儲到主機內存中,等待GPU執行。GPU執行時通過主機接口獲取到圖形指令,并解析執行,將圖形指令轉換為圖形參數配置和圖形數據。圖形參數配置和圖形數據通過圖形處理流水處理生成幀緩沖中的數據。圖形處理流水在GPU實現包括固定圖形流水實現方式和可編程染色陣列實現方式。
目前,OpenGL、Direct X及公開的資料中可編程染色器完成的部分包括頂點染色、幾何染色、片段染色。其余圖元組裝、光柵化由固定圖形流水方式實現。
2 圖形處理性能分析
通過上述抽象的統一渲染架構GPU圖形處理模型,可得一次圖形處理過程主要包括:主機圖形指令生成,主機接口總線數據傳輸,圖形指令解析,圖形處理流水處理。其中圖形處理流水由統一染色器陣列和固定圖形流水完成。圖形處理量化性能模型如圖4所示。
主機圖形指令生成實現圖形API到圖形指令的運行時轉換,存儲到主機內存的Ringbuffer中;主機接口總線數據傳輸完成圖形指令、數據從主機內存Ringbuffer到圖形處理器的搬運;圖形指令解析完成圖形指令到圖形參數配置、圖形數據的轉換;統一染色器陣列和固定圖形流水配合完成圖形流水處理。
在圖形處理系統設計過程中均衡各部分性能是圖形處理系統性能發揮、資源有效利用的關鍵所在。下面將對各部分性能指標進行量化分析。
2.1 主機圖形指令生成
主機圖形指令生成由運行在主機上的運行時編譯軟件完成,其性能由主機處理器性能和GPU運行時圖形指令編譯驅動決定。圖形API在運行時編譯過程中會進行圖形上下文管理、圖形參數處理、圖形指令生成、存儲等操作。如OpenGL開源實現Mesa 3D以及AMD的開源顯卡驅動中的主機圖形指令生成軟件實現,如圖5所示。
通過不完全分析統計,目前開源的圖形API運行時編譯普遍消耗200條指令以上的CPU匯編指令。為便于分析,假定圖形API運行時編譯平均消耗200條的CPU匯編指令,即在1 000 MIPS處理能力的主機環境下,圖形指令的生成能力為5 MGIPS(Million Graphic Instructions Per Second)[10]。
圖形API所攜帶的參數種類多、個數雜,圖形指令在定義時一般都采用變長的包格式定義。如ATI Radeon R5xx所定義的圖形指令格式,如圖6所示。由于圖形處理大部分為4維操作,如vertex(x,y,z,w)、color(R,G,B,A),圖形API所攜帶的參數大部分為4個。以ATI Radeon R5xx Type-0圖形指令格式為例,大部分的圖形API所生成的圖形指令為5個字(20 Byte)。
由此,1 000 MIPS處理能力的主機環境下,圖形指令生成能力約為5 MGIPS,數據量約為1 00 MB/s。以奔騰4 HT 3.6 GHz主機環境為例,其能夠提供7 GFLOPS計算能力,其圖形指令生成能力約35 MGIPS,700 MB/s。
2.2 主機接口總線數據傳輸
目前流行的GPU主機接口有PCI、AGP、PCIE,各總線理論帶寬如表1所示,一般的實現中帶寬利用率在70%左右,因此在奔騰4 HT 3.6 GHz主機環境主機環境下,主機接口帶寬要求至少為1.0 GB/s,由此可見至少占用PCIE1.0 x4進行圖形指令數據傳輸。
2.3 圖形指令解析
圖形命令解析在GPU實現普遍采用RSIC處理器方式實現(CMD),如AMD R700。以R700架構HD4870GPU為例,其運行頻率為700 MHz,要完成35 MGIPS的圖形指令處理,即需要20周期完成一條圖形指令的解析。若圖形指令從存儲在GPU內部的顯示列表來,其指令解析能力要求將遠超35 MGIPS。圖形指令解析后將生成圖形參數配置或圖形數據,圖形參數配置實現對各級圖形流水運行狀態或參數的配置,圖形數據則經過圖形流水各級進行圖形處理。
2.4 圖形處理流水
圖形處理流水包括三個階段:頂點階段、幾何階段、像素(片段)階段,如圖7所示。頂點階段針對獨立的頂點數據進行處理,所處理頂點之間不存在相關性,評價指標為:頂點/秒,圖元裝配負責將頂點階段處理完的孤立的頂點組織成點、線段、三角形 3種幾何圖元。幾何階段負責對點、線段、三角形進行裁剪、消隱等處理,不同圖元處理的方法、算法有很大差異,因此幾何階段的評價指標包括:點/秒、線段/秒、三角形/秒。光柵化完成幾何數據的離散化處理,將連續的幾何數據轉換為離散的片段數據。片段階段和像素階段都是對離散的像素數據進行處理,片段數據和像素數據的區別在于像素數據僅有位置和坐標信息,而片段數據幾乎包含頂點所攜帶的所有屬性,如紋理坐標、霧坐標等。為方便起見片段階段處理和像素階段處理的性能指標統一為:像素/秒。
頂點階段、幾何階段、像素階段之間性能指標存在一定相關性,頂點階段根據圖元類型的不同頂點數據和幾何數據成特定比例關系,如表2所示。
而幾何階段與像素階段的數據由繪制圖形的大小決定,點圖元由pointsize決定,線段由線段的長度和linewidth決定,三角形由面積決定,也就是幾何圖元和像素的比例關系決定性能瓶頸。
以三角形為例:當TRIANGLE:PIXEL > (三角形/秒)/(像素/秒),性能瓶頸將處于幾何階段;當TRIANGLE:PIXEL < (三角形/秒)/(像素/秒),性能瓶頸將處于像素階段。
在實際GPU圖形處理過程中,性能瓶頸可能出現在圖形流水的任何階段,具體與各處理階段性能指標、實現方式、繪制圖形的特征密切相關。如某GPU在設計性能指標為頂點階段處理50兆頂點/秒,幾何階段100兆三角形/秒,像素階段1 000 兆像素/秒,由上述可知該圖形流水性能指標設計不合理,原因在于VERTEX:TRIANGLE最多1:1,即一個頂點生成1個三角形,因此50兆頂點/秒的頂點處理能力最多需要50兆三角形/秒的幾何處理能力。
在圖形處理流水中,頂點處理、幾何處理、片段處理采用統一染色陣列實現方式,統一染色陣列實現方式能夠動態平衡各流水階段處理的性能要求,但同一染色陣列的性能需與固定處理單元性能參數保持平衡才能發揮出最優的圖形處理能力。
2.5 統一染色陣列
圖形處理中頂點處理、幾何處理、片段處理采用可編程方式實現,以AMD、NVIDIA為代表的GPU廠家目前都采用SIMD、SIMT的統一染色陣列方式實現[13]。統一染色陣列不同階段任務之間以固定管線實現圖形流水線的連接。即固定管線為統一染色陣列提供圖形數據的輸入、輸出功能。如圖8所示,統一染色陣列運行過程中首先接收固定管線傳遞的圖形數據,然后根據染色陣列工作狀態采用一定的任務調度策略、線程調度策略將圖形數據傳遞給特定的染色器,然后啟動染色器運行,染色器處理完成后將圖形數據傳遞給固定管線,進行下一階段處理。染色器在處理過程中,從染色程序區取得待處理的染色器指令,以數據并行、線程并行、指令并行的處理方式實現圖形處理。
由此,統一染色陣列圖形處理性能主要由固定管線的圖形任務或者圖形數據提供能力,染色器任務調度、線程調度能力,染色器線程并行能力,染色器任務執行能力等決定。在系統設計時只有在典型應用情況下各方面能力保持均衡,統一染色陣列圖形處理性能才能得到發揮。
固定管線的圖形任務或者圖形數據提供能力主要涉及數據的生成和傳輸能力,OpenGL規定染色器輸入輸出至少16組4維屬性,若固定管線實現單周期任務處理能力,以目前典型32位圖形處理系統為例,單周期實現16×4×32=2 048位數據的傳輸和處理。
任務調度、線程調度能力指根據染色器的工作方式和當前工作狀態將固定管線的圖形任務或者圖形數據分配到特定的染色器上的能力。如圖8染色器工作方式為4組4維處理方式,即一個圖形處理線程可執行4個頂點或像素。
染色器線程并行為了提高染色器處理資源的利用率,通過多個獨立的線程的切換執行隱藏長延時指令的執行時間。染色器線程處理方式與圖形數據的普遍形式相關,能夠在保證資源利用率高的情況下盡可能提高數據處理的并行性。如在實際應用過程中典型的像素塊都是4×4的像素塊,則數據并行需處理為16,典型圖形數據又包含4個分量,即一套取值單元為16×4=64個染色器內核提供指令。
染色器任務執行能力由任務軟件的運行指令數量和指令執行的并行能力決定,這與具體圖形任務劃分、染色器處理單元實現方式、發射結構等密切相關。各廠家實現方式,甚至面向不同應用領域的實現方式都存在較大差異。
2.6 性能均衡分析
在具體圖形處理器設計過程中各階段性能均衡對性能的發揮至關重要,通過上述各部分性能指標描述可得以下公式:
式(1)體現圖形任務的數據生成效率與傳輸效率保持一致,而在系統應用中典型的通信鏈路速率利用率普遍為70%左右。
式(2)表示圖形指令的生成要小于等于圖形指令解析速率,因為在OpenGL等圖形接口中定義有顯示列表等其他高速通路的圖形指令傳輸路徑。在具體實現中圖形指令眾多,各指令處理性能千差萬別,應用對指令的引用也不盡相同,因此評價性能時根據具體實現對指令處理進行分類,統計應用中各類指令所占權值,按照加權平均方式對圖形指令生成、處理性能進行評價。
式(3)通過統計經驗值建立主機性能與圖形指令生成之間的關系。
式(4)體現圖形處理中頂點階段與幾何階段的性能應保持相當,在具體處理性能應與實際應用中點、線、三角形占比相關。
式(5)建立像素處理性能與幾何處理性能之間的關系,圖元面積與繪圖分辨率息息相關。
式(6)建立染色器性能與圖形任務處理性能之間關系,通過發射圖形任務所包含的指令值執行總周期數與處理該任務所需的染色器總執行周期數,確定線程并行、數據并行、指令并行處理與圖形任務性能的參數映射。
3 應用及結果分析
自研嵌入式圖形處理器設計指標中規定三角形圖元處理能力為150 M/s,像素處理能力為4 G/s,包含運行頻率600 MHz的統一染色陣列。
通過式(4)可得:頂點階段處理能力為150 M/s,幾何階段三角形處理能力為150 M/s;若頂點數據全部由主機指令生成,則至少150 M/s圖形指令,以數據量最大的4維浮點數頂點為例,數據量為150×4×4=2 400 MB/s,通過式(1)可得需要主機通信速率約為3.4 GB/s,至少PCIE 2.0 x8才能滿足帶寬需求。通過式(2)可得圖形指令解析速率不小于150 MGIPS;經不完全統計通過匯編級優化的自研圖形處理器驅動約50條主機指令生成一條典型圖形指令,通過式(3)可得需要主機性能為7.5 GIPS。
通過式(5)分析,當圖元面積大于4 G/150 M約28個像素時,像素階段性能會成為性能瓶頸,反之為頂點、幾何階段。
可編程染色陣列峰值任務生成率為150 M頂點,150 M三角形,4 G像素,由于在設計中典型的頂點、幾何、像素染色成運行指令數據接近,約處理300條染色器指令,由此圖形任務約為4.3 G。設計中像素采用4×4 Tile進行處理,因此以16個圖形任務組成一個處理線程,一個任務由4個處理核心組成4維向量處理,即一個線程控制64個處理核心,通過式(6)可得每秒染色器線程調度速為4.3 G/16=268.75 M。染色內核擬采用雙發射結構,運行頻率為600 MHz,通過式(7)可得268.75 M×(300/2)=600 M×(內核數/16),即內核數應為1 075個,為便于設計設計內核數為1 024個。由此形成自研嵌入式圖形處理器指標參數見表3。
通過在體系結構仿真平臺上模擬表3所示的設計參數,并針對各模塊以及整系統峰值進行測試,測試數據表明,實測性能指標與預期指標誤差小于7.5%,能夠有效支撐工程設計。
4 結論
本文在深入研究統一渲染架構GPU架構和工作原理基礎上,提出一種統一渲染架構GPU的圖形處理量化性能模型,并應用于自研嵌入式圖形處理器設計中。仿真驗證結果表明,該模型評估統一染色GPU圖形處理性能與實測相比,誤差小于7.5%。但目前研究僅從圖形處理方面進行研究,尚未完全覆蓋GPU設計的所有單元,尤其是未對存儲系統、染色器陣列實現方式等進行分析。后續將從統一渲染架構GPU整體架構出發,研究各部分處理模塊性能的關系,進一步提高模型的全面性和精度。
參考文獻
[1] 蔡晶.GPGPU體系結構關鍵技術論證及模擬器研究與擴展[D].長沙:國防科學技術大學,2009.
[2] 韓博,周秉鋒.GPGPU性能模型及應用實例分析[D].北京:北京大學計算機科學與技術研究所,2009.
[3] 王鋒,杜云飛,陳娟.GPGPU性能模型研究[D].長沙:國防科學技術大學,2013.
[4] 朱俊峰,陳鋼,張珂良,等.面向OpenCL架構的GPGPU量化性能模型[J].小型微型計算機系統,2013,34(5):1118-1125.
[5] FEINBUBE F,TROGER P,POLZE A.Joint forces:from multithreadedprogramming to GPU computing[J].IEEE Software,2010,28(1):51-57.
[6] BUCK I,FOLEY T,HORN D,et al.Brook for GPUs:stream-computing on graphics hardware[J].ACM Transactions on Graphics,2004,23(3):777-786.
[7] GALOPPO N,GOVINDARTJU N K,HENSON M,et al.LU-GPU:Efficient algorithms for solving dense linear systems on graphics hardware[C].SC′05:Proceedings of the 2005 ACM/IEEE Conference on Supercomputing,2005.
[8] LUEBKE D,HUMPHREYS G.How GPUs work[J].IEEE Computer,2007,40(2):96-100.
[9] 韓俊剛,劉有耀,張曉.圖形處理器的歷史現狀和發展趨勢[J].西安郵電學院學報,2011,16(3):61-64.
[10] GOVINDARAJU N K,LARSEN S,GRAY J,et al.A memory model for scientific algo rithms on graphics processors[C].Proceedings of the ACM IEEE Conference on Supercomputing,Tampa,2006:1-6.
[11] WILLIAMS S,WATERMAN A,PATTERSON D.Roofline:an insightful visual performance model for multicore architectures[J].Communications of the ACM,2009,52(4):65-76.
[12] 王之元.并行計算可擴展性分析與優化——能耗、可靠性和計算性能[D].長沙:國防科學技術大學,2011.
[13] 趙榮彩,唐志敏,張兆慶,等.軟件流水的低功耗編譯技術研究[J].軟件學報,2003,14(8):1357-1363.
[14] HUANG M,RENAU J,TORRELLAS J.Profile-based energy reduction for high-performance processors[Z].2001.
[15] 熊英,羅瓊.基于OpenCL的NDVI算法的并行化實現[J].電腦開發與應用,2013(11):77-78.
[16] 詹云,趙新燦,譚同德.基于OpenCL的異構系統并行編程[J].計算機工程與設計,2012,33(11):4191-4195.
作者信息:
馬城城1,2,田 澤1,2,黎小玉1,2,孫琳娜3
(1.中國航空工業西安航空計算技術研究所 ,陜西 西安710068;
2.集成電路與微系統設計航空科技重點實驗室,陜西 西安710068;3.西安翔騰微電子科技有限公司,陜西 西安710068)