|
定義一臺抽象機器，用于描述 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)存上的帶寬負(fù)載可能會特別高，每一片段也都有多個讀-改-寫運算，盡管緩存可能會稍稍緩減這一問題。這一對高帶寬存取的需求反過來推動了對具備許多針腳的寬內(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)的帶寬和功耗，而且還能夠提供低成本的抗鋸齒功能。那么，有些什么劣勢呢? 任何基于區(qū)塊的渲染方案的主要額外開銷是從頂點著色器到片段著色器的交接點。幾何處理階段的輸出、各頂點可變數(shù)和區(qū)塊中間狀態(tài)必須寫出到主內(nèi)存，再由片段處理階段重新讀取。因此，必須要在可變數(shù)據(jù)和區(qū)塊狀態(tài)消耗的額外帶寬與幀緩沖數(shù)據(jù)節(jié)省的帶寬之間取得平衡。 當(dāng)今的現(xiàn)代消費類電子設(shè)備正大步向更高分辨率顯示屏邁進;1080p 現(xiàn)在已是智能手機的常態(tài)，配備Mali-T604 的 Google Nexus 10 等平板電腦以 WQXGA (2560x1600) 分辨率運行，而 4k2k 正逐漸成為電視機市場上新的“不二之選”。屏幕分辨率以及幀緩沖帶寬正快速發(fā)展。在這一方面，Mali 確實表現(xiàn)出眾，而且以對應(yīng)用程序開發(fā)人員基本透明的方式實現(xiàn) - 無需任何代價，就能獲得所有這些好處，而且還不用更改應(yīng)用程序! 在幾何處理方面，Mali 也能處理好復(fù)雜度。許多高端基準(zhǔn)測試正在接近每幀百萬個三角形，其復(fù)雜度比 Android 應(yīng)用商店中的熱門游戲應(yīng)用程序高出一個(或兩個)數(shù)量級。然而，由于中間幾何數(shù)據(jù)的確到達主內(nèi)存，所以可以應(yīng)用一些有用的技巧和訣竅，來優(yōu)化 GPU 性能并充分發(fā)揮系統(tǒng)能力。這些技巧值得通過一篇博文來細談，所以我們會在這一系列的后續(xù)博文中再予以介紹。 小結(jié) 在這篇博文中，我比較了桌面型直接模式渲染器與 Mali 所用的基于區(qū)塊方式的異同，尤其探討了兩種方式對內(nèi)存帶寬的影響。 |
