圖形工作負(fù)載的優(yōu)化對于許多現(xiàn)代移動應(yīng)用程序而言往往必不可少，因?yàn)閹缀跛袖秩粳F(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ì)致地洞悉整個(gè)系統(tǒng)的行為，但也需要駕馭它的工程師能夠解讀相關(guān)數(shù)據(jù)，識別問題區(qū)域，進(jìn)而提出修復(fù)建議。

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

抽象渲染機(jī)器

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

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

CPU-GPU 渲染管線

基于區(qū)塊的渲染

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

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

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

務(wù)必要了解的一個(gè)基本知識是，OpenGL ES API 上應(yīng)用程序函數(shù)調(diào)用和這些 API 調(diào)用所需渲染運(yùn)算的執(zhí)行之間的臨時(shí)關(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ā)實(shí)際的繪制運(yùn)算。由于 API是同步的，執(zhí)行繪制調(diào)用后的所有 API 行為都被指定為要像渲染運(yùn)算已經(jīng)發(fā)生一樣進(jìn)行，但在幾乎所有硬件加速的 OpenGL ES 實(shí)現(xiàn)上，這只是一種由驅(qū)動程序堆棧維持的美妙假象。

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

管線化

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

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

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

管線節(jié)流

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

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

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

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

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

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