移動GPU三種主流架構優缺點淺析_GPU

來源:互聯網
上載者:User



導讀: GPU是Graphic Processor Unit的簡稱,顧名思義就是圖形處理器。 GPU的概念最早是從圖形工作站發展而來,從90年代的個人電腦普及開始,GPU迎來了其大發展的時代。 在90年代中期,案頭GPU經曆了2D到3D的跨越,從此3D圖形渲染取代2D成為PC遊戲的主流
1. 移動GPU與案頭GPU移動GPU相對案頭GPU只能算是小弟弟。 移動GPU的劣勢主要表現在理論效能和頻寬。 移動GPU受限於晶片的面積,能耗以及成本所以必須犧牲部分效能和頻寬來求得性價比和電池續航力的平衡。 與案頭GPU動輒256bit甚至512bit的位寬、1.2-1.5GHz的高頻顯存相比,移動GPU不僅要和CPU共用記憶體頻寬,而且普遍使用的是雙32bit位寬、LPDDR2-800或1066左右的記憶體系統,總頻寬普遍在10GB/s以內


在上圖中移動處理器中記憶體頻寬最高的是iPad 3/4,因為他們使用Retina螢幕,2048x1536的高解析度對GPU頻寬要求更高,不過就算是這兩款產品,17GB/s的頻寬與PC顯卡上動輒200GB/s以上的頻寬相比還是小兒科。 沒有高頻寬就沒有大容量紋理資料,也就不會擁有高畫質。 儘管頻寬不是制約移動GPU發展的唯一因素,但是在目前的限制下,移動GPU廠商關心的頭、、大事就是如何在儘可能小的頻寬需求下提升GPU效能及畫質,紋理壓縮是一個方法,還有一種就是使用不同的渲染架構。 目前在GPU領域主要有IMR、TBR及TBDR、三種主流架構 2. 移動GPU的模式
2.1. IMR模式

IMR(Immediate Mode Rendering)就如字面意思一樣,提交的每個渲染命令都會立即開始執行,並且該渲染命令會在整條流水線中執行完畢後才開始執行下一個渲染命令
這種模式的優點:
1. GPU架構比TBR模式簡單直接
2. 在一幀裡面執行FBO操作時,不會因為需要清空緩衝的渲染指令而影響效能
3. 不用像TBR架構一樣需要片上快取來儲存中間結果
4. 不用像TBR架構一樣緩衝Triangle List,因此在有大量頂點運算的情境時比TBR有優勢。 例如PC上面的複雜模型可能有幾百萬個triangle
這種模式的缺點就是:
1. IMR的渲染會存在浪費頻寬的情況。 例如,當兩次渲染有前後遮蔽關係時,IMR模式因為兩次draw命令都要執行,因此會存在經過Pixel Shader後的Pixel被Depth test拋棄,這樣就浪費了Shader Unit運算能力。 不過幸運的是,目前幾乎所有的IMR架構的GPU都會提供Early Z的判斷方式,一般是在Rasterizer裡面對圖形的遮蔽關係進行判斷,如果需要渲染的圖形被遮擋住,那麼就直接拋棄該圖形而不需要執行Pixel Shader
2. IMR的另外一個缺點就是其渲染命令在執行需要隨時讀寫frame buffer,depth buffer和stencil buffer,這帶來大量的記憶體頻寬消耗,在移動平台上面訪問片外記憶體是最消耗電量和最耗時的操作
因此在案頭GPU領域,TBR節省頻寬和低效能不符合PC機的要求,IMR一統江湖。 但是在移動GPU領域,TBR的低頻寬消耗,低功耗正好滿足行動裝置需求,與其在PC端的待遇相反,行動裝置領域TBR幾乎一統江湖
3.2. TBR模式與IMR簡單粗暴的做法不同,TBR(Tile Based Rendering)它將需要渲染的畫面分成一個個的矩形區塊(tile),tile一般是4x4或者8x4的矩形塊。 模型的頂點經過Vertex Shader運算以後會組裝成一個個的triangle,這些triangle會被緩衝在一個triangle cache裡面。 如果某個triangle需要在某個tile裡面繪製,那麼就會在該tile的triangle list中存一個索引。 、、一幀裡面所有的渲染命令都經執行完Vertex Shader產生triangle以後,每個tile就會擁有一個triangle list,這list就包含了需要在該tile內部繪製的所有triangle。 然後GPU再基於triangle list執行每個tile的raster和Per-fragment operation
TBR的優點是:
執行raster和Per-fragment operation時不需要反覆的訪問frame buffer,depth buffer,stencil buffer。 這是因為GPU可以把整個tile的frame buffer/depth buffer/stencil buffer儲存在一個片上的快取中,這樣GPU就直接存取tile,而不需要訪問外部記憶體。 這大大減少了記憶體的頻寬消耗,也意味著能耗的降低
TBR的缺點是:
需要儲存Vertex Shader執行後的結果以及每個tile的triangle list。 這意味著如果情境裡面有很多的頂點,那麼片上緩衝就不可能存下這麼多頂點資訊和triangle list,就不得不依靠外部記憶體來儲存,就會擁有額外的頻寬消耗。 不過慶幸的是當前的移動3D繪製都不會擁有太多的triangle的情境。 一個複雜的模型也就1萬多個triangle,因此一個通常的情境大概就是幾十萬triangle。 隨著移動遊戲越來越複雜精美,模型的複雜程度也會快速上升,這也是TBR架構在未來將會面臨的一大挑戰
如果在一幀裡面有兩遍及其以上的渲染,那麼就需要使用Frame buffer object來緩衝中間結果,這對TBR又是一大效能損耗。 根據我們前面的講解,TBR需要緩衝一幀所有的圖元,所有圖元執行完畢後才開始raster和Per-fragment operation。 在這種情況下,一旦後面的draw命令需要使用到前面渲染產生的結果,那麼就不得不在該命令執行前,要求GPU把緩衝的所有draw命令都執行完畢,然後放棄當前緩衝內容。 在極致情況下,例如每次draw都需要讀取前一次draw渲染的結果,那麼TBR就會直接退化成IMR模式基於以上的缺點,我們可以看出在案頭GPU領域TBR沒有任何優勢,因此其完全退出案頭GPU市場。 但是在移動GPU市場它更能適應效能/頻寬/能耗三者的平衡
3.3. TBDR模式



TBDR(Tile Based Deferred Rendering,貼圖延遲渲染)算是TBR的近親,它跟TBR原理相似,但是通過HSR(Hidden Surface Removal,隱藏面消除)操作,在執行Pixel Shader之前進一步減少了不需要渲染的fragment,降低了頻寬需求。 在執行Pixel Shader之前,對Raster產生的每個像素都做depth test的比較,剔除被遮擋的像素,這就是HSR的原理。 理論上經過HSR剔除以後,TBDR每幀需要渲染的像素上限就是螢幕像素的數量(沒有考慮alpha blend的情況下)。 而傳統的TBR在執行複雜一點的遊戲時可能需要渲染6倍於螢幕的像素
TBDR是PowerVR的王牌,因為TBR和HSR帶來的頻寬與運算開銷的降低,使得手機的續航能力讓人驚歎。 下圖是PowerVR的SGX系列的GPU架構圖,可以看到其複雜程度的架構




導讀: GPU是Graphic Processor Unit的簡稱,顧名思義就是圖形處理器。 GPU的概念最早是從圖形工作站發展而來,從90年代的個人電腦普及開始,GPU迎來了其大發展的時代。 在90年代中期,案頭GPU經曆了2D到3D的跨越,從此3D圖形渲染取代2D成為PC遊戲的主流
1. 移動GPU與案頭GPU移動GPU相對案頭GPU只能算是小弟弟。 移動GPU的劣勢主要表現在理論效能和頻寬。 移動GPU受限於晶片的面積,能耗以及成本所以必須犧牲部分效能和頻寬來求得性價比和電池續航力的平衡。 與案頭GPU動輒256bit甚至512bit的位寬、1.2-1.5GHz的高頻顯存相比,移動GPU不僅要和CPU共用記憶體頻寬,而且普遍使用的是雙32bit位寬、LPDDR2-800或1066左右的記憶體系統,總頻寬普遍在10GB/s以內


在上圖中移動處理器中記憶體頻寬最高的是iPad 3/4,因為他們使用Retina螢幕,2048x1536的高解析度對GPU頻寬要求更高,不過就算是這兩款產品,17GB/s的頻寬與PC顯卡上動輒200GB/s以上的頻寬相比還是小兒科。 沒有高頻寬就沒有大容量紋理資料,也就不會擁有高畫質。 儘管頻寬不是制約移動GPU發展的唯一因素,但是在目前的限制下,移動GPU廠商關心的頭、、大事就是如何在儘可能小的頻寬需求下提升GPU效能及畫質,紋理壓縮是一個方法,還有一種就是使用不同的渲染架構。 目前在GPU領域主要有IMR、TBR及TBDR、三種主流架構 2. 移動GPU的模式
2.1. IMR模式

IMR(Immediate Mode Rendering)就如字面意思一樣,提交的每個渲染命令都會立即開始執行,並且該渲染命令會在整條流水線中執行完畢後才開始執行下一個渲染命令
這種模式的優點:
1. GPU架構比TBR模式簡單直接
2. 在一幀裡面執行FBO操作時,不會因為需要清空緩衝的渲染指令而影響效能
3. 不用像TBR架構一樣需要片上快取來儲存中間結果
4. 不用像TBR架構一樣緩衝Triangle List,因此在有大量頂點運算的情境時比TBR有優勢。 例如PC上面的複雜模型可能有幾百萬個triangle
這種模式的缺點就是:
1. IMR的渲染會存在浪費頻寬的情況。 例如,當兩次渲染有前後遮蔽關係時,IMR模式因為兩次draw命令都要執行,因此會存在經過Pixel Shader後的Pixel被Depth test拋棄,這樣就浪費了Shader Unit運算能力。 不過幸運的是,目前幾乎所有的IMR架構的GPU都會提供Early Z的判斷方式,一般是在Rasterizer裡面對圖形的遮蔽關係進行判斷,如果需要渲染的圖形被遮擋住,那麼就直接拋棄該圖形而不需要執行Pixel Shader
2. IMR的另外一個缺點就是其渲染命令在執行需要隨時讀寫frame buffer,depth buffer和stencil buffer,這帶來大量的記憶體頻寬消耗,在移動平台上面訪問片外記憶體是最消耗電量和最耗時的操作
因此在案頭GPU領域,TBR節省頻寬和低效能不符合PC機的要求,IMR一統江湖。 但是在移動GPU領域,TBR的低頻寬消耗,低功耗正好滿足行動裝置需求,與其在PC端的待遇相反,行動裝置領域TBR幾乎一統江湖
3.2. TBR模式與IMR簡單粗暴的做法不同,TBR(Tile Based Rendering)它將需要渲染的畫面分成一個個的矩形區塊(tile),tile一般是4x4或者8x4的矩形塊。 模型的頂點經過Vertex Shader運算以後會組裝成一個個的triangle,這些triangle會被緩衝在一個triangle cache裡面。 如果某個triangle需要在某個tile裡面繪製,那麼就會在該tile的triangle list中存一個索引。 、、一幀裡面所有的渲染命令都經執行完Vertex Shader產生triangle以後,每個tile就會擁有一個triangle list,這list就包含了需要在該tile內部繪製的所有triangle。 然後GPU再基於triangle list執行每個tile的raster和Per-fragment operation
TBR的優點是:
執行raster和Per-fragment operation時不需要反覆的訪問frame buffer,depth buffer,stencil buffer。 這是因為GPU可以把整個tile的frame buffer/depth buffer/stencil buffer儲存在一個片上的快取中,這樣GPU就直接存取tile,而不需要訪問外部記憶體。 這大大減少了記憶體的頻寬消耗,也意味著能耗的降低
TBR的缺點是:
需要儲存Vertex Shader執行後的結果以及每個tile的triangle list。 這意味著如果情境裡面有很多的頂點,那麼片上緩衝就不可能存下這麼多頂點資訊和triangle list,就不得不依靠外部記憶體來儲存,就會擁有額外的頻寬消耗。 不過慶幸的是當前的移動3D繪製都不會擁有太多的triangle的情境。 一個複雜的模型也就1萬多個triangle,因此一個通常的情境大概就是幾十萬triangle。 隨著移動遊戲越來越複雜精美,模型的複雜程度也會快速上升,這也是TBR架構在未來將會面臨的一大挑戰
如果在一幀裡面有兩遍及其以上的渲染,那麼就需要使用Frame buffer object來緩衝中間結果,這對TBR又是一大效能損耗。 根據我們前面的講解,TBR需要緩衝一幀所有的圖元,所有圖元執行完畢後才開始raster和Per-fragment operation。 在這種情況下,一旦後面的draw命令需要使用到前面渲染產生的結果,那麼就不得不在該命令執行前,要求GPU把緩衝的所有draw命令都執行完畢,然後放棄當前緩衝內容。 在極致情況下,例如每次draw都需要讀取前一次draw渲染的結果,那麼TBR就會直接退化成IMR模式基於以上的缺點,我們可以看出在案頭GPU領域TBR沒有任何優勢,因此其完全退出案頭GPU市場。 但是在移動GPU市場它更能適應效能/頻寬/能耗三者的平衡
3.3. TBDR模式



TBDR(Tile Based Deferred Rendering,貼圖延遲渲染)算是TBR的近親,它跟TBR原理相似,但是通過HSR(Hidden Surface Removal,隱藏面消除)操作,在執行Pixel Shader之前進一步減少了不需要渲染的fragment,降低了頻寬需求。 在執行Pixel Shader之前,對Raster產生的每個像素都做depth test的比較,剔除被遮擋的像素,這就是HSR的原理。 理論上經過HSR剔除以後,TBDR每幀需要渲染的像素上限就是螢幕像素的數量(沒有考慮alpha blend的情況下)。 而傳統的TBR在執行複雜一點的遊戲時可能需要渲染6倍於螢幕的像素
TBDR是PowerVR的王牌,因為TBR和HSR帶來的頻寬與運算開銷的降低,使得手機的續航能力讓人驚歎。 下圖是PowerVR的SGX系列的GPU架構圖,可以看到其複雜程度的架構



聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.