0 引言

    從1999年NVIDIA發(fā)布第一款GPU產品至今，GPU技術發(fā)展主要經歷了固定功能流水線階段、分離染色器架構階段、統(tǒng)一染色器架構階段^[1]。其處理架構的不斷改變使得圖形處理能力和計算能力不斷提升，相應的流水線結構、并行計算結構、并行數(shù)據(jù)通信結構、存儲結構越發(fā)復雜，圖形處理性能指標已難以從單方面去設計、評價。研究GPU圖形處理性能模型意義重大。

    國外NVIDIA、AMD等公司針對GPU圖形處理性能方面進行了大量研究，但都是各公司的核心機密，公開甚少^[2]。國內在統(tǒng)一渲染架構GPU性能方面進行了一定理論探討，但主要集中在并行計算、存儲結構、編程優(yōu)化方面，針對GPU設計本身的研究幾乎空白。

    本文提出統(tǒng)一渲染架構GPU圖形處理量化性能模型，在分析統(tǒng)一渲染架構GPU并行架構和工作原理基礎上，分析影響圖形處理的各種因素：圖形指令生成、主機接口數(shù)據(jù)傳輸、圖形指令解析、圖形處理流水數(shù)據(jù)吞吐和統(tǒng)一染色陣列處理能力。為統(tǒng)一渲染架構GPU的性能參數(shù)設計提供方法支持。

1 統(tǒng)一渲染架構GPU圖形處理模型

    圖形處理器經過近30年的發(fā)展，雖然圖形處理器體系結構、處理方式發(fā)生了巨大變化，但其基于Z-Buffer的光柵化圖形處理流水線一直沿用至今^[3]。自2006年，NVIDIA發(fā)布統(tǒng)一渲染架構的GPU以來，統(tǒng)一渲染架構便成為GPU的主流^[4]。NVIDIA、AMD等各廠家都有自己不同的實現(xiàn)方式，但基本的CPU+GPU異構工作方式、圖形處理流程都基本一致^[5-6]。下文將在分析代表產品的基礎上，針對圖形處理性能抽象統(tǒng)一渲染架構GPU圖形處理模型。

1.1 GeForce 8800

    GeForce 8800是2006年NVIDIA發(fā)布的第一款統(tǒng)一染色架構GPU，采用G80架構^[7]。自此NVIDIA每兩年發(fā)布一款GPU架構。2006年發(fā)布G80，2008年發(fā)布Tesla-GT200，2010年發(fā)布Fermi-GF100，2012年發(fā)布kepler，2014年發(fā)布年Maxwell，2016年發(fā)布Pascal。每一款GPU架構都對染色陣列數(shù)量及結構進行優(yōu)化、調整，但圖形處理過程改變甚微，基本保持著G80的處理過程，如圖1所示。

    圖形處理任務由主機生成圖形指令存儲到主機內存中，GPU通過主機接口獲取圖形指令，然后將圖形指令解析為統(tǒng)一染色陣列和固定的硬件單元的控制和數(shù)據(jù)信息，配合完成圖形處理過程。

1.2 R700

    R700是2008年AMD公司發(fā)布的具有大規(guī)模SIMD統(tǒng)一染色陣列的圖形處理器架構^[6]，結構如圖2所示。其存儲系統(tǒng)包括兩部分，一部分是駐于主機內存中的系統(tǒng)空間，另一部分則是位于GPU上的顯存空間。存儲系統(tǒng)中包含的數(shù)據(jù)包括命令隊列、指令、常數(shù)以及輸入、輸出流，其中命令隊列指明了GPU需要處理的任務；指令給出了執(zhí)行部件的具體工作；常數(shù)、輸入和輸出流則提供了計算所需要的數(shù)據(jù)，這幾個部分要素構成了GPU運行的基本要素。

    一個完整R700的應用分為兩個部分：運行在主機CPU上的主機程序和運行在GPU DPP陣列（Data-Parallel Processor，下文稱為染色陣列）上的kernel程序。應用在運行過程中主機程序生成染色陣列運行所需的數(shù)據(jù)、染色器程序及需執(zhí)行的命令。GPU通過主機接口獲取主機生成的命令后由命令處理器（Command Processor）解析并控制固定處理單元和染色陣列運行，完成圖形處理。

1.3 統(tǒng)一渲染架構GPU圖形處理摸模型

    抽象統(tǒng)一渲染架構GPU圖形處理過程，如圖3所示，包括主機指令生成、主機接口數(shù)據(jù)傳輸、圖形指令解析、固定圖形流水單元處理和統(tǒng)一染色陣列處理。主機和GPU通過“生產-消費者”關系工作，圖形指令是主機和GPU交互的“橋梁”，主機圖形指令生成負責圖形API運行時生成圖形指令，存儲到主機內存中，等待GPU執(zhí)行。GPU執(zhí)行時通過主機接口獲取到圖形指令，并解析執(zhí)行，將圖形指令轉換為圖形參數(shù)配置和圖形數(shù)據(jù)。圖形參數(shù)配置和圖形數(shù)據(jù)通過圖形處理流水處理生成幀緩沖中的數(shù)據(jù)。圖形處理流水在GPU實現(xiàn)包括固定圖形流水實現(xiàn)方式和可編程染色陣列實現(xiàn)方式。

    目前，OpenGL、Direct X及公開的資料中可編程染色器完成的部分包括頂點染色、幾何染色、片段染色。其余圖元組裝、光柵化由固定圖形流水方式實現(xiàn)。

2 圖形處理性能分析

    通過上述抽象的統(tǒng)一渲染架構GPU圖形處理模型，可得一次圖形處理過程主要包括：主機圖形指令生成，主機接口總線數(shù)據(jù)傳輸，圖形指令解析，圖形處理流水處理。其中圖形處理流水由統(tǒng)一染色器陣列和固定圖形流水完成。圖形處理量化性能模型如圖4所示。

    主機圖形指令生成實現(xiàn)圖形API到圖形指令的運行時轉換，存儲到主機內存的Ringbuffer中；主機接口總線數(shù)據(jù)傳輸完成圖形指令、數(shù)據(jù)從主機內存Ringbuffer到圖形處理器的搬運；圖形指令解析完成圖形指令到圖形參數(shù)配置、圖形數(shù)據(jù)的轉換；統(tǒng)一染色器陣列和固定圖形流水配合完成圖形流水處理。

    在圖形處理系統(tǒng)設計過程中均衡各部分性能是圖形處理系統(tǒng)性能發(fā)揮、資源有效利用的關鍵所在。下面將對各部分性能指標進行量化分析。

2.1 主機圖形指令生成

    主機圖形指令生成由運行在主機上的運行時編譯軟件完成，其性能由主機處理器性能和GPU運行時圖形指令編譯驅動決定。圖形API在運行時編譯過程中會進行圖形上下文管理、圖形參數(shù)處理、圖形指令生成、存儲等操作。如OpenGL開源實現(xiàn)Mesa 3D以及AMD的開源顯卡驅動中的主機圖形指令生成軟件實現(xiàn)，如圖5所示。

    通過不完全分析統(tǒng)計，目前開源的圖形API運行時編譯普遍消耗200條指令以上的CPU匯編指令。為便于分析，假定圖形API運行時編譯平均消耗200條的CPU匯編指令，即在1 000 MIPS處理能力的主機環(huán)境下，圖形指令的生成能力為5 MGIPS(Million Graphic Instructions Per Second)^[10]。

    圖形API所攜帶的參數(shù)種類多、個數(shù)雜，圖形指令在定義時一般都采用變長的包格式定義。如ATI Radeon R5xx所定義的圖形指令格式，如圖6所示。由于圖形處理大部分為4維操作，如vertex（x，y，z，w）、color（R，G，B，A），圖形API所攜帶的參數(shù)大部分為4個。以ATI Radeon R5xx Type-0圖形指令格式為例，大部分的圖形API所生成的圖形指令為5個字（20 Byte）。

    由此，1 000 MIPS處理能力的主機環(huán)境下，圖形指令生成能力約為5 MGIPS，數(shù)據(jù)量約為1 00 MB/s。以奔騰4 HT 3.6 GHz主機環(huán)境為例，其能夠提供7 GFLOPS計算能力，其圖形指令生成能力約35 MGIPS，700 MB/s。

2.2 主機接口總線數(shù)據(jù)傳輸

    目前流行的GPU主機接口有PCI、AGP、PCIE，各總線理論帶寬如表1所示，一般的實現(xiàn)中帶寬利用率在70%左右，因此在奔騰4 HT 3.6 GHz主機環(huán)境主機環(huán)境下，主機接口帶寬要求至少為1.0 GB/s，由此可見至少占用PCIE1.0 x4進行圖形指令數(shù)據(jù)傳輸。

2.3 圖形指令解析

    圖形命令解析在GPU實現(xiàn)普遍采用RSIC處理器方式實現(xiàn)（CMD），如AMD R700。以R700架構HD4870GPU為例，其運行頻率為700 MHz，要完成35 MGIPS的圖形指令處理，即需要20周期完成一條圖形指令的解析。若圖形指令從存儲在GPU內部的顯示列表來，其指令解析能力要求將遠超35 MGIPS。圖形指令解析后將生成圖形參數(shù)配置或圖形數(shù)據(jù)，圖形參數(shù)配置實現(xiàn)對各級圖形流水運行狀態(tài)或參數(shù)的配置，圖形數(shù)據(jù)則經過圖形流水各級進行圖形處理。

2.4 圖形處理流水

    圖形處理流水包括三個階段：頂點階段、幾何階段、像素（片段）階段，如圖7所示。頂點階段針對獨立的頂點數(shù)據(jù)進行處理，所處理頂點之間不存在相關性，評價指標為：頂點/秒，圖元裝配負責將頂點階段處理完的孤立的頂點組織成點、線段、三角形 3種幾何圖元。幾何階段負責對點、線段、三角形進行裁剪、消隱等處理，不同圖元處理的方法、算法有很大差異，因此幾何階段的評價指標包括：點/秒、線段/秒、三角形/秒。光柵化完成幾何數(shù)據(jù)的離散化處理，將連續(xù)的幾何數(shù)據(jù)轉換為離散的片段數(shù)據(jù)。片段階段和像素階段都是對離散的像素數(shù)據(jù)進行處理，片段數(shù)據(jù)和像素數(shù)據(jù)的區(qū)別在于像素數(shù)據(jù)僅有位置和坐標信息，而片段數(shù)據(jù)幾乎包含頂點所攜帶的所有屬性，如紋理坐標、霧坐標等。為方便起見片段階段處理和像素階段處理的性能指標統(tǒng)一為：像素/秒。

    頂點階段、幾何階段、像素階段之間性能指標存在一定相關性，頂點階段根據(jù)圖元類型的不同頂點數(shù)據(jù)和幾何數(shù)據(jù)成特定比例關系，如表2所示。

    而幾何階段與像素階段的數(shù)據(jù)由繪制圖形的大小決定，點圖元由pointsize決定，線段由線段的長度和linewidth決定，三角形由面積決定，也就是幾何圖元和像素的比例關系決定性能瓶頸。

    以三角形為例：當TRIANGLE：PIXEL  > （三角形/秒）/（像素/秒），性能瓶頸將處于幾何階段；當TRIANGLE：PIXEL  < （三角形/秒）/（像素/秒），性能瓶頸將處于像素階段。

    在實際GPU圖形處理過程中，性能瓶頸可能出現(xiàn)在圖形流水的任何階段，具體與各處理階段性能指標、實現(xiàn)方式、繪制圖形的特征密切相關。如某GPU在設計性能指標為頂點階段處理50兆頂點/秒，幾何階段100兆三角形/秒，像素階段1 000 兆像素/秒，由上述可知該圖形流水性能指標設計不合理，原因在于VERTEX:TRIANGLE最多1：1，即一個頂點生成1個三角形，因此50兆頂點/秒的頂點處理能力最多需要50兆三角形/秒的幾何處理能力。

    在圖形處理流水中，頂點處理、幾何處理、片段處理采用統(tǒng)一染色陣列實現(xiàn)方式，統(tǒng)一染色陣列實現(xiàn)方式能夠動態(tài)平衡各流水階段處理的性能要求，但同一染色陣列的性能需與固定處理單元性能參數(shù)保持平衡才能發(fā)揮出最優(yōu)的圖形處理能力。

2.5 統(tǒng)一染色陣列

    圖形處理中頂點處理、幾何處理、片段處理采用可編程方式實現(xiàn)，以AMD、NVIDIA為代表的GPU廠家目前都采用SIMD、SIMT的統(tǒng)一染色陣列方式實現(xiàn)[13]。統(tǒng)一染色陣列不同階段任務之間以固定管線實現(xiàn)圖形流水線的連接。即固定管線為統(tǒng)一染色陣列提供圖形數(shù)據(jù)的輸入、輸出功能。如圖8所示，統(tǒng)一染色陣列運行過程中首先接收固定管線傳遞的圖形數(shù)據(jù)，然后根據(jù)染色陣列工作狀態(tài)采用一定的任務調度策略、線程調度策略將圖形數(shù)據(jù)傳遞給特定的染色器，然后啟動染色器運行，染色器處理完成后將圖形數(shù)據(jù)傳遞給固定管線，進行下一階段處理。染色器在處理過程中，從染色程序區(qū)取得待處理的染色器指令，以數(shù)據(jù)并行、線程并行、指令并行的處理方式實現(xiàn)圖形處理。

    由此，統(tǒng)一染色陣列圖形處理性能主要由固定管線的圖形任務或者圖形數(shù)據(jù)提供能力，染色器任務調度、線程調度能力，染色器線程并行能力，染色器任務執(zhí)行能力等決定。在系統(tǒng)設計時只有在典型應用情況下各方面能力保持均衡，統(tǒng)一染色陣列圖形處理性能才能得到發(fā)揮。

    固定管線的圖形任務或者圖形數(shù)據(jù)提供能力主要涉及數(shù)據(jù)的生成和傳輸能力，OpenGL規(guī)定染色器輸入輸出至少16組4維屬性，若固定管線實現(xiàn)單周期任務處理能力，以目前典型32位圖形處理系統(tǒng)為例，單周期實現(xiàn)16×4×32=2 048位數(shù)據(jù)的傳輸和處理。

    任務調度、線程調度能力指根據(jù)染色器的工作方式和當前工作狀態(tài)將固定管線的圖形任務或者圖形數(shù)據(jù)分配到特定的染色器上的能力。如圖8染色器工作方式為4組4維處理方式，即一個圖形處理線程可執(zhí)行4個頂點或像素。

    染色器線程并行為了提高染色器處理資源的利用率，通過多個獨立的線程的切換執(zhí)行隱藏長延時指令的執(zhí)行時間。染色器線程處理方式與圖形數(shù)據(jù)的普遍形式相關，能夠在保證資源利用率高的情況下盡可能提高數(shù)據(jù)處理的并行性。如在實際應用過程中典型的像素塊都是4×4的像素塊，則數(shù)據(jù)并行需處理為16，典型圖形數(shù)據(jù)又包含4個分量，即一套取值單元為16×4=64個染色器內核提供指令。

    染色器任務執(zhí)行能力由任務軟件的運行指令數(shù)量和指令執(zhí)行的并行能力決定，這與具體圖形任務劃分、染色器處理單元實現(xiàn)方式、發(fā)射結構等密切相關。各廠家實現(xiàn)方式，甚至面向不同應用領域的實現(xiàn)方式都存在較大差異。

2.6 性能均衡分析

    在具體圖形處理器設計過程中各階段性能均衡對性能的發(fā)揮至關重要，通過上述各部分性能指標描述可得以下公式：

    式(1)體現(xiàn)圖形任務的數(shù)據(jù)生成效率與傳輸效率保持一致，而在系統(tǒng)應用中典型的通信鏈路速率利用率普遍為70%左右。

    式(2)表示圖形指令的生成要小于等于圖形指令解析速率，因為在OpenGL等圖形接口中定義有顯示列表等其他高速通路的圖形指令傳輸路徑。在具體實現(xiàn)中圖形指令眾多，各指令處理性能千差萬別，應用對指令的引用也不盡相同，因此評價性能時根據(jù)具體實現(xiàn)對指令處理進行分類，統(tǒng)計應用中各類指令所占權值，按照加權平均方式對圖形指令生成、處理性能進行評價。

    式(3)通過統(tǒng)計經驗值建立主機性能與圖形指令生成之間的關系。

    式(4)體現(xiàn)圖形處理中頂點階段與幾何階段的性能應保持相當，在具體處理性能應與實際應用中點、線、三角形占比相關。

    式(5)建立像素處理性能與幾何處理性能之間的關系，圖元面積與繪圖分辨率息息相關。

    式(6)建立染色器性能與圖形任務處理性能之間關系，通過發(fā)射圖形任務所包含的指令值執(zhí)行總周期數(shù)與處理該任務所需的染色器總執(zhí)行周期數(shù)，確定線程并行、數(shù)據(jù)并行、指令并行處理與圖形任務性能的參數(shù)映射。

3 應用及結果分析

    自研嵌入式圖形處理器設計指標中規(guī)定三角形圖元處理能力為150 M/s，像素處理能力為4 G/s，包含運行頻率600 MHz的統(tǒng)一染色陣列。

    通過式(4)可得：頂點階段處理能力為150 M/s，幾何階段三角形處理能力為150 M/s；若頂點數(shù)據(jù)全部由主機指令生成，則至少150 M/s圖形指令，以數(shù)據(jù)量最大的4維浮點數(shù)頂點為例，數(shù)據(jù)量為150×4×4=2 400 MB/s，通過式(1)可得需要主機通信速率約為3.4 GB/s，至少PCIE 2.0 x8才能滿足帶寬需求。通過式(2)可得圖形指令解析速率不小于150 MGIPS；經不完全統(tǒng)計通過匯編級優(yōu)化的自研圖形處理器驅動約50條主機指令生成一條典型圖形指令，通過式(3)可得需要主機性能為7.5 GIPS。

    通過式(5)分析，當圖元面積大于4 G/150 M約28個像素時，像素階段性能會成為性能瓶頸，反之為頂點、幾何階段。

    可編程染色陣列峰值任務生成率為150 M頂點，150 M三角形，4 G像素，由于在設計中典型的頂點、幾何、像素染色成運行指令數(shù)據(jù)接近，約處理300條染色器指令，由此圖形任務約為4.3 G。設計中像素采用4×4 Tile進行處理，因此以16個圖形任務組成一個處理線程，一個任務由4個處理核心組成4維向量處理，即一個線程控制64個處理核心，通過式(6)可得每秒染色器線程調度速為4.3 G/16=268.75 M。染色內核擬采用雙發(fā)射結構，運行頻率為600 MHz，通過式(7)可得268.75 M×（300/2）=600 M×(內核數(shù)/16)，即內核數(shù)應為1 075個，為便于設計設計內核數(shù)為1 024個。由此形成自研嵌入式圖形處理器指標參數(shù)見表3。

    通過在體系結構仿真平臺上模擬表3所示的設計參數(shù)，并針對各模塊以及整系統(tǒng)峰值進行測試，測試數(shù)據(jù)表明，實測性能指標與預期指標誤差小于7.5%，能夠有效支撐工程設計。

4 結論

    本文在深入研究統(tǒng)一渲染架構GPU架構和工作原理基礎上，提出一種統(tǒng)一渲染架構GPU的圖形處理量化性能模型，并應用于自研嵌入式圖形處理器設計中。仿真驗證結果表明，該模型評估統(tǒng)一染色GPU圖形處理性能與實測相比，誤差小于7.5%。但目前研究僅從圖形處理方面進行研究，尚未完全覆蓋GPU設計的所有單元，尤其是未對存儲系統(tǒng)、染色器陣列實現(xiàn)方式等進行分析。后續(xù)將從統(tǒng)一渲染架構GPU整體架構出發(fā)，研究各部分處理模塊性能的關系，進一步提高模型的全面性和精度。

參考文獻

[1] 蔡晶.GPGPU體系結構關鍵技術論證及模擬器研究與擴展[D].長沙：國防科學技術大學，2009.

[2] 韓博，周秉鋒.GPGPU性能模型及應用實例分析[D].北京：北京大學計算機科學與技術研究所，2009.

[3] 王鋒，杜云飛，陳娟.GPGPU性能模型研究[D].長沙：國防科學技術大學，2013.

[4] 朱俊峰，陳鋼，張珂良，等.面向OpenCL架構的GPGPU量化性能模型[J].小型微型計算機系統(tǒng)，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，F(xiàn)OLEY 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] 韓俊剛，劉有耀，張曉.圖形處理器的歷史現(xiàn)狀和發(fā)展趨勢[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] 王之元.并行計算可擴展性分析與優(yōu)化——能耗、可靠性和計算性能[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算法的并行化實現(xiàn)[J].電腦開發(fā)與應用，2013(11)：77-78.

[16] 詹云，趙新燦，譚同德.基于OpenCL的異構系統(tǒng)并行編程[J].計算機工程與設計，2012，33(11)：4191-4195.

作者信息:

馬城城1，2，田  澤1，2，黎小玉1，2，孫琳娜3 

（1.中國航空工業(yè)西安航空計算技術研究所 ，陜西 西安710068；

2.集成電路與微系統(tǒng)設計航空科技重點實驗室，陜西 西安710068；3.西安翔騰微電子科技有限公司，陜西 西安710068）