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

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

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

　　Streamline 中找出這些問題。

　　抽象渲染機器

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

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

　　CPU-GPU 渲染管線

　　基于區(qū)塊的渲染

　　著色器核心架構

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

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

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

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

　　管線化

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

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

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

　　管線節(jié)流

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

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

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

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

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

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

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

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

　　小結

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