ARM Mali GPU: 抽象機(jī)器（一）：幀管線化

　　圖形工作負(fù)載的優(yōu)化對于許多現(xiàn)代移動應(yīng)用程序而言往往必不可少，因為幾乎所有渲染現(xiàn)在都直接或間接地由基于 OpenGL ES 的渲染后端負(fù)責(zé)處理。本文介紹如何將 ARM®DS-5™ Streamline™ 性能分析工具用于 Google Nexus 10，對利用Mali™-T604 GPU 的圖形應(yīng)用程序進(jìn)行性能分析和優(yōu)化。Streamline 是一款強(qiáng)大的工具，能夠深入細(xì)致地洞悉整個系統(tǒng)的行為，但也需要駕馭它的工程師能夠解讀相關(guān)數(shù)據(jù)，識別問題區(qū)域，進(jìn)而提出修復(fù)建議。

　　對于初涉圖形優(yōu)化的開發(fā)人員而言，起步階段總會遇到一些困難，所以我寫了新的系列博文，給開發(fā)人員提供必要的知識，以便他們能夠成功地針對 Mali GPU進(jìn)行優(yōu)化。在整個系列博文中，我將闡述開發(fā)人員必須要考慮的基本宏觀體系結(jié)構(gòu)和行為、這些因素如何轉(zhuǎn)化為能被內(nèi)容觸發(fā)的潛在問題，以及最終如何在

　　Streamline 中找出這些問題。

　　抽象渲染機(jī)器

　　要想成功分析應(yīng)用程序的圖形性能，必須先掌握一個最基本的知識，也就是對 OpenGL ES API 底下系統(tǒng)運作方式建立一個心智模型，讓工程師能夠推斷他們觀察到的行為。

　　為避免讓開發(fā)人員陷于驅(qū)動程序軟件和硬件子系統(tǒng)的實施細(xì)節(jié)的沼澤之中(這些他們無法控制，因而價值有限)，有必要定義一個簡化的抽象機(jī)器，用作解讀所觀察到的行為的基礎(chǔ)。這一機(jī)器包含三個有用部分，它們大體上是獨立不相干的，所以我將在本系列博文的開頭幾篇中逐一介紹。不過，為了讓你對它們有個初步印象，下面列出該模型的三個部分：

　　CPU-GPU 渲染管線

　　基于區(qū)塊的渲染

　　著色器核心架構(gòu)

　　在本篇博文中，我們將探討第一個部分，即 CPU-GPU 渲染管線。

　　同步API，異步執(zhí)行

　　務(wù)必要了解的一個基本知識是，OpenGL ES API 上應(yīng)用程序函數(shù)調(diào)用和這些 API 調(diào)用所需渲染運算的執(zhí)行之間的臨時關(guān)系。從應(yīng)用程序的角度而言，OpenGL ES API被指定為同步 API。應(yīng)用程序進(jìn)行一系列的函數(shù)調(diào)用來設(shè)置其下一繪制任務(wù)所需的狀態(tài)，然后調(diào)用 glDraw[1] 函數(shù)(通常稱為繪制調(diào)用)觸發(fā)實際的繪制運算。由于 API是同步的，執(zhí)行繪制調(diào)用后的所有 API 行為都被指定為要像渲染運算已經(jīng)發(fā)生一樣進(jìn)行，但在幾乎所有硬件加速的 OpenGL ES 實現(xiàn)上，這只是一種由驅(qū)動程序堆棧維持的美妙假象。

　　與繪制調(diào)用相似，驅(qū)動程序維持的第二個假象是幀末緩沖翻轉(zhuǎn)。大多數(shù)頭一次編寫 OpenGL ES 應(yīng)用程序的開發(fā)人員會告訴你，調(diào)用 eglSwapBuffers將交換其應(yīng)用程序的前緩沖和后緩沖。雖然這在邏輯上是對的，但驅(qū)動程序再一次維持了同步性的假象;在幾乎所有平臺上，實際的緩沖交換可能會在很久之后才會發(fā)生。

　　管線化

　　正如你所想到的，需要創(chuàng)造這一假象的原因在于性能。如果我們強(qiáng)制渲染運算真正同步發(fā)生，你就會面臨這樣的尷尬：CPU 忙于創(chuàng)建下一繪制運算的狀態(tài)時，GPU 會閑置;GPU 執(zhí)行渲染時，CPU 會閑置。對于以性能為重的加速器而言，所有這些閑置時間都是絕然不可接受的。

　　為了去除這一閑置時間，我們使用 OpenGL ES 驅(qū)動程序來維持同步渲染行為的假象，而在面紗之后實際是以異步執(zhí)行的方式處理渲染和幀交換。通過異步運行，我們可以建立一個小小的工作儲備以允許創(chuàng)建一個管線，GPU 從管線的一端處理較舊的工作負(fù)載，而 CPU 則負(fù)責(zé)將新的工作推入另一端。這一方式的優(yōu)勢在于，只要管線裝滿，就始終有工作在 GPU 上運行，提供最佳的性能。

　　Mali GPU 管線中的工作單元是以渲染目標(biāo)為單位進(jìn)行計劃的，其中渲染目標(biāo)可能是屏幕緩存或離屏緩存。單個渲染目標(biāo)通過兩步處理。首先，GPU 為渲染目標(biāo)中的所有繪制調(diào)用處理頂點著色[2]。然后，為整個渲染目標(biāo)處理片段著色[3]。因此，Mali 的邏輯渲染管線包含三個階段：CPU 處理階段、幾何處理階段，以及片段處理階段。

　　管線節(jié)流

　　觀察力敏銳的讀者可能已注意到，上圖中片段部分的工作是三個運算中最慢的，被 CPU 和幾何處理階段甩得越來越遠(yuǎn)。這種情形并不少見;大多數(shù)內(nèi)容中要著色的片段遠(yuǎn)多于頂點，因此片段著色通常是占主導(dǎo)地位的處理運算。

　　在現(xiàn)實中，最好要盡可能縮短從 CPU 工作結(jié)束到幀被渲染之間的延時 – 對最終用戶而言，最讓人煩躁的莫過于在操作觸控屏設(shè)備時，其觸控事件輸入和屏幕中數(shù)據(jù)顯示之間出現(xiàn)數(shù)百毫秒的不同步 – 所以，我們不希望等待片段處理階段的工作儲備變得過大。簡而言之，我們需要某種機(jī)制來定期減慢 CPU 線程，當(dāng)管線足夠滿、能夠維持良好性能時停止把工作放入隊列。

　　這種節(jié)流機(jī)制通常由主機(jī)窗口系統(tǒng)提供，而不是圖形驅(qū)動程序本身。例如，在 Android 上，我們只有在知道緩沖方向時才能處理任何繪制運算，因為用戶可能會旋轉(zhuǎn)其設(shè)備，造成幀大小出現(xiàn)變化。SurfaceFlinger— Android 窗口表面管理器 – 可以通過一個簡單方式控制管線深度：當(dāng)管線中排隊等待渲染的緩沖數(shù)量超過 N 個時，拒絕將緩沖返回到應(yīng)用程序的圖形堆棧。

　　如果出現(xiàn)這種情形，你就會看到：一旦每一幀達(dá)到“N”時 CPU 就會進(jìn)入閑置狀態(tài)，在內(nèi)部阻止 EGL 或 OpenGL

　　ES API 函數(shù)，直到顯示屏消耗完一個待處理緩存，為新的渲染運算空出一個位置。

　　如果圖形堆棧的運行快于顯示刷新率，同樣的方案也可限制管線緩沖;在這一情形下，內(nèi)容受到VSYNC限制”并等待垂直空白(VSYNC同步)信號，該信號告訴顯示控制器它可以切換到下一緩沖。如果 GPU 產(chǎn)生幀的速度快于顯示屏顯示幀的速度，那么

　　SurfaceFlinger 將積累一定數(shù)量已經(jīng)完成渲染但依然需要顯示在屏幕上的緩沖;即使這些緩沖不再是 Mali 管線的一個部分，它們依然算在應(yīng)用程序進(jìn)程的 N 幀限制內(nèi)。

　　正如上面的管線示意圖所示，如果內(nèi)容受到VSYNC同步限制，那么會經(jīng)常出現(xiàn) CPU 和 GPU 都完全閑置的時段。平臺動態(tài)電壓和頻率調(diào)節(jié) (DVFS) 通常會在此類情形中嘗試降低當(dāng)前的工作頻率，以降低電壓和功耗，但由于 DVFS 頻率選擇通常相對粗糙，所以可能會出現(xiàn)一定數(shù)量的閑置時間。

　　小結(jié)

　　本篇博文中，我們探討了 OpenGL ES API 提供的同步假象，以及 API 下實際運行異步渲染管線的原因。