Mali GPU: 抽象機器(二) C 基于區(qū)塊的渲染

定義一臺抽象機器，用于描述 Mali GPU和驅(qū)動程序軟件對應(yīng)用程序可見的行為。此機器的用意是為開發(fā)人員提供 OpenGL ES API 下有趣行為的一個心智模型，而這反過來也可用于解釋影響其應(yīng)用程序性能的問題。我在本系列后面幾篇博文中繼續(xù)使用這一模型，探討開發(fā)人員在開發(fā)圖形應(yīng)用程序時常常遇到的一些性能缺口。

這篇博文將繼續(xù)開發(fā)這臺抽象機器，探討 Mali GPU系列基于區(qū)塊的渲染模型。你應(yīng)該已經(jīng)閱讀了關(guān)于管線化的第一篇博文;如果還沒有，建議你先讀一下。

“傳統(tǒng)”方式

在傳統(tǒng)的主線驅(qū)動型桌面 GPU 架構(gòu)中 — 通常稱為直接模式架構(gòu) — 片段著色器按照順序在每一繪制調(diào)用、每一原語上執(zhí)行。每一原語渲染結(jié)束后再開始下一個，其利用類似于如下所示的算法：

1. foreach( primitive )

2. foreach( fragment )

3. render fragment

由于流中的任何三角形可能會覆蓋屏幕的任何部分，由這些渲染器維護的數(shù)據(jù)工作集將會很大;通常至少包含全屏尺寸顏色緩沖、深度緩沖，還可能包含模板緩沖?，F(xiàn)代設(shè)備的典型工作集是 32 位/像素 (bpp) 顏色，以及 32 bpp 封裝的深度/模板。因此，1080p 顯示屏擁有一個 16MB 工作集，而 4k2k 電視機則有一個 64MB 工作集。由于其大小原因，這些工作緩沖必須存儲在芯片外的 DRAM 中。

每一次混合、深度測試和模板測試運算都需要從這一工作集中獲取當(dāng)前片段像素坐標(biāo)的數(shù)據(jù)值。被著色的所有片段通常會接觸到這一工作集，因此在高清顯示中，置于這一內(nèi)存上的帶寬負載可能會特別高，每一片段也都有多個讀-改-寫運算，盡管緩存可能會稍稍緩減這一問題。這一對高帶寬存取的需求反過來推動了對具備許多針腳的寬內(nèi)存接口和專用高頻率內(nèi)存的需求，這兩者都會造成能耗特別密集的外部內(nèi)存訪問。

Mali 方式

Mali GPU 系列采用非常不同的方式，通常稱為基于區(qū)塊的的渲染，其設(shè)計宗旨是竭力減少渲染期間所需的功耗巨大的外部內(nèi)存訪問。如本系列第一篇博文中所述，Mali 對每一渲染目標(biāo)使用獨特的兩步驟渲染算法。它首先執(zhí)行全部的幾何處理，然后執(zhí)行所有的片段處理。在幾何處理階段中，Mali GPU 將屏幕分割為微小的16x16 像素區(qū)塊，并對每個區(qū)塊中存在的渲染原語構(gòu)建一份清單。GPU 片段著色步驟開始時，每一著色器核心一次處理一個 16x16 像素區(qū)塊，將它渲染完后再開始下一區(qū)塊。對于基于區(qū)塊的架構(gòu)，其算法相當(dāng)于：

1. foreach( tile )

2. foreach( primitive in tile )

3. foreach( fragment in primitive in tile )

4. render fragment

由于 16x16 區(qū)塊僅僅是總屏幕面積的一小部分，所以有可能將整個區(qū)塊的完整工作集(顏色、深度和模板)存放在和 GPU 著色器核心緊密耦合的快速 RAM 中。

這種基于區(qū)塊的方式有諸多優(yōu)勢。它們大體上對開發(fā)人員透明，但也值得了解，尤其是在嘗試了解你內(nèi)容的帶寬成本時：

對工作集的所有訪問都屬于本地訪問，速度快、功耗低。讀取或?qū)懭胪獠?DRAM 的功耗因系統(tǒng)設(shè)計而異，但對于提供的每 1GB/s 帶寬，它很容易達到大約 120mW。與這相比，內(nèi)部內(nèi)存訪問的功耗要大約少一個數(shù)量級，所以你會發(fā)現(xiàn)這真的大有關(guān)系。

混合不僅速度快，而且功耗低，因為許多混合方式需要的目標(biāo)顏色數(shù)據(jù)都隨時可用。

區(qū)塊足夠小，我們實際上可以在區(qū)塊內(nèi)存中本地存儲足夠數(shù)量的樣本，實現(xiàn) 4 倍、8 倍和 16 倍多采樣抗鋸齒1。這可提供質(zhì)量高、開銷很低的抗鋸齒。由于涉及的工作集大小(一般單一采樣渲染目標(biāo)的 4、8 或 16 倍;4k2k 顯示面板的 16x MSAA需要巨大的 1GB 工作集數(shù)據(jù))，少數(shù)直接模式渲染器甚至將 MSAA 作為一項功能提供給開發(fā)人員，因為外部內(nèi)存大小和帶寬通常導(dǎo)致其成本過于高昂。

Mali 僅僅需要將單一區(qū)塊的顏色數(shù)據(jù)寫回到區(qū)塊末尾的內(nèi)存，此時我們便能知道其最終狀態(tài)。我們可以通過 CRC 檢查將塊的顏色與主內(nèi)存中的當(dāng)前數(shù)據(jù)進行比較 — 這一過程叫做“事務(wù)消除”— 如果區(qū)塊內(nèi)容相同，則可完全跳過寫出，從而節(jié)省了 SoC 功耗。我的同事 Tom Olson 針對這一技術(shù)寫了一篇 優(yōu)秀的博文，文中還提供了“事務(wù)消除”的一個現(xiàn)實世界示例(某個名叫“憤怒的小鳥”的游戲;你或許聽說過)。有關(guān)這一技術(shù)的詳細信息還是由 Tom 的博文來介紹;不過，這兒也稍稍了解一下該技術(shù)的運用(僅“多出的粉色”區(qū)塊由 GPU 寫入 - 其他全被成功丟棄)。

我們可以采用快速的無損壓縮方案 — ARM 幀緩沖壓縮 (AFBC) — ，對逃過事務(wù)消除的區(qū)塊的顏色數(shù)據(jù)進行壓縮，從而進一步降低帶寬和功耗。這一壓縮可以應(yīng)用到離屏 FBO 渲染目標(biāo)，后者可在隨后的渲染步驟中由 GPU 作為紋理讀回;也可以應(yīng)用到主窗口表面，只要系統(tǒng)中存在兼容 AFBC 的顯示控制器，如 Mali-DP500。

大多數(shù)內(nèi)容擁有深度緩沖和模板緩沖，但幀渲染結(jié)束后就不必再保留其內(nèi)容。如果開發(fā)人員告訴 Mali 驅(qū)動程序不需要保留深度緩沖和模板緩沖2— 理想方式是通過調(diào)用 glDiscardFramebufferEXT (OpenGL ES 2.0) 或 glInvalidateFramebuffer (OpenGLES 3.0)，雖然在某些情形中可由驅(qū)動程序推斷 — 那么區(qū)塊的深度內(nèi)容和模板內(nèi)容也就徹底不用寫回到主內(nèi)存中。我們又大幅節(jié)省了帶寬和功耗!

上表中可以清晰地看出，基于區(qū)塊的渲染具有諸多優(yōu)勢，尤其是可以大幅降低與幀緩沖數(shù)據(jù)相關(guān)的帶寬和功耗，而且還能夠提供低成本的抗鋸齒功能。那么，有些什么劣勢呢?