學習教程來自:【技術美術百人計劃】圖形 3.7 移動端TB(D)R架構基礎

移動端GPU的TB(D)R架構

1. 當前移動端GPU概況

市場占比概況（數據來自學習教程PPT）

1.1 移動端和桌面端功耗對比

移動端和桌面端功耗對比（數據來自學習教程PPT）差距約100倍

1.2 移動端和桌面端帶寬對比

移動端和桌面端帶寬對比（來自學習教程PPT）差距約10倍

2. 名詞解釋

SoC(System on Chip)：芯片。把CPU GPU 內存 通信基帶 GPS模塊等整合在一起的芯片
System Memory：手機內存。CPU和GPU共用的一塊片內LPDDR物理內存，一般有幾個G
On-chip Memory：緩存。CPU和GPU的高速SRAM的Cache緩存，一般幾百K到幾M，比內存快幾倍到幾十倍，他們都共享內存地址空間（桌面端是分開的）。在TB(D)R架構下會存儲Tile的顏色、深度和模板緩沖
Stall：GPU必須串行的2次計算之間的等待過程
FillRate：ROP運行時鐘頻率 X ROP個數 X 每個時鐘ROP可以處理的像素個數
TB(D)R/Tile-Based(Deferred)Rendering：主流的移動GPU渲染架構，對應PC的IMR(Immediate Mode Rendering)。屏幕被分成16或32的像素塊渲染
TBR流程：VS-Defer-RS-PS
TBDS流程：VS-Defer-RS-Defer-PS（見7、8描述2個defer過程）
Defer：延遲，阻塞+批處理待渲染的一幀中的多個數據，然后一起處理

3. 立即渲染(IMR)

IMR工作流程（來自https://www.imaginationtech.com/）

4. 基于塊元的渲染TB(D)R

逐個圖元（頂點著色+圖元加入TileList）：階段1執行幾何相關的處理，生成Primitive List/圖元列表，確定Tile上的圖元有哪些

逐個分塊（片元著色等）：逐Tile執行光柵化和后續處理，完成后將Frame Buffer從Tile Buffer寫回System Memory中

5. TB(D)R的硬件渲染順序

TB(D)R工作流程（來自https://www.imaginationtech.com/）

6. IMR和TB(D)R對比

TB(D)R對比和IMR對比（來自學習教程PPT）

總體上看，TBR降低了功耗和帶寬，但幀率上并不比IMR快

TBR的優缺點：

優點：

TBR有利于消除OverDraw，其中PowerVR的HSR技術和Mali的Forward Pixel Killing技術，都最大限度的減少了被遮擋像素的texturing和shading

Cached Friendly，在緩存中的讀寫速度遠高于全局內存，以降低render rate的代價，減低了帶寬和功耗。

缺點：

binning過程：在VS過程后輸出幾何數據到DDR，然后被FS讀取，幾何數據過多的情況下可能在此處產生性能瓶頸

當三角形覆蓋在多個tile上時，需要繪制很多次，此時性能低于IMR模式

7. Binning過程（第一個Defer）

過程：圖元分配到對應的塊元

Binning過程（來自學習教程PPT）

測試工具：Adreno Profiler

8. 不同GPU的Early-Depth-Test（第二個Defer）

8.1 Qualcomm Adreno的LDR（Android）

硬件的occlusion culling：在正常渲染管線之前，VS生成低精度depth texture，剔除不可見的三角形

8.2 Mali的FPK（Android）

Forward Pixel Kill技術：在Early-Z階段之后，使用一個FIFO隊列拋棄被遮擋的Quad（例子中是2*2的像素）

FPK過程（來自學習教程PPT）

8.3 Power-VR的HSR（IOS）

Hidden Surface Removal技術：沿一條射線從第一個不透明片元向后剔除被遮擋的片元

HSR過程（來自學習教程PPT）

9. 優化建議

不使用FrameBuffer時及時Clear或Discard：清空了在tile buffer上的中間數據。Unity中，不適用RT時調用Discard。OpenGL ES中善用glClear、glInvalidateFrameBuffer，避免不必要的Resolve（tile buffer刷新到系統內存）行為

減少一幀中FrameBuffer綁定的頻繁切換：減少了tile buffer和系統內存之間的stall操作

考察Alpha Test和Alpha混合的實際表現，合理使用。減少Alpha混合實現透明時的混合范圍（例如將透明區域的Mesh裁剪掉替換為多邊形）

使用Alpha Test時先進行提前深度測試

圖片盡量壓縮，例如ASTC ETC2

圖片盡量開啟mipmap

貼圖采樣：UV值盡量使用VS中傳出的Varying變量（VS向PS中傳遞的變量）（連續），不要再FS中動態計算UV（非連續），造成CacheMiss

在延遲渲染中盡量利用Tile Buffer

項目配置中不同的配置導致的幀率變化，可能是帶寬占用的問題

MSAA在TBDR下消耗很小：硬件速度快

減少FS中Clip(HLSL)、discard(GLSL)、gl_FragDepth的使用：會打斷Early-DT的執行

區分使用float、half、fix：1). 降低帶寬占用 2). 減少GPU周期提高并行程度 3). 降低統一變量寄存器數量，從而降低寄存器數量溢出風險，參考Unity3D shader優化技巧集合

減少FrameData壓力：頂點處理部分容易成為瓶頸，應避免使用曲面細分shader、置換貼圖等負操作。提倡使用模型LOD，且盡早進行遮擋剔除（如umbra）

作業

題目：打包場景到Android平臺，對比優化前和優化后的結果
測試環境：2.84 GHz 驍龍865八核 8GB運存
提前總結：以下優化效果測試了貼圖大小的影響，關閉了一些影響不大的后處理效果，沒有進行shader的修改（菜~~ 沒找到shader的位置，之后再完善吧）。

0. 優化前

場景來自Unity Asset 資源鏈接

優化前 PPT 1500ms
優化前 1500ms

優化1：從上邊的圖看，瓶頸在GPU。經過嘗試后關閉了攝像機中一個后處理（遠處場景模糊處理），

1. 關閉耗時的后處理

關閉1個后處理 36.88ms

2. 貼圖調整

貼圖調整前 為2048X2048 38ms左右

Texture Compression設置為ETC：沒啥效果，依舊為38ms，看來默認就會有一些壓縮

Max Size 2048 -> 256 -> 32：差別不大，降低了5ms左右，畫質變差了很多。可能由于開啟了MipMap，遠處的貼圖降低了分辨率，近處的物體也不是很多。還有可能由于手機的性能瓶頸不在這里，故調整貼圖大小差別不大

貼圖調整為32X32 34ms
如圖，當攝像機離散的變化到一個新位置時，渲染的時間會突然增加再慢慢減少，往復循環。

3. Shader

場景中使用的材質
這個場景里的Shader沒找到從哪里能改，卒

4. 一些后處理效果的刪除

經測試，關掉這些后處理效果能在最終效果差別不大的情況下提升幀率（貼圖在2048分辨率下）

關閉的效果
關閉后 平均28ms左右（關閉前38ms） 最高33ms 與貼圖改到 32X32 分辨率結果相近
效果圖
優化前

總結

以上是生活随笔為你收集整理的技美知识学习3700：现代移动端的TBR和TBDR渲染管线的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。