|
圖形工作負載的優化對于許多現代移動應用程序而言往往必不可少，因為幾乎所有渲染現在都直接或間接地由基于 OpenGL ES 的渲染后端負責處理。本文介紹如何將 ARM?DS-5? Streamline? 性能分析工具用于 Google Nexus 10，對利用Mali?-T604 GPU 的圖形應用程序進行性能分析和優化。Streamline 是一款強大的工具，能夠深入細致地洞悉整個系統的行為，但也需要駕馭它的工程師能夠解讀相關數據，識別問題區域，進而提出修復建議。 對于初涉圖形優化的開發人員而言，起步階段總會遇到一些困難，所以我寫了新的系列博文，給開發人員提供必要的知識，以便他們能夠成功地針對 Mali GPU進行優化。在整個系列博文中，我將闡述開發人員必須要考慮的基本宏觀體系結構和行為、這些因素如何轉化為能被內容觸發的潛在問題，以及最終如何在 Streamline 中找出這些問題。 抽象渲染機器 要想成功分析應用程序的圖形性能，必須先掌握一個最基本的知識，也就是對 OpenGL ES API 底下系統運作方式建立一個心智模型，讓工程師能夠推斷他們觀察到的行為。 為避免讓開發人員陷于驅動程序軟件和硬件子系統的實施細節的沼澤之中(這些他們無法控制，因而價值有限)，有必要定義一個簡化的抽象機器，用作解讀所觀察到的行為的基礎。這一機器包含三個有用部分，它們大體上是獨立不相干的，所以我將在本系列博文的開頭幾篇中逐一介紹。不過，為了讓你對它們有個初步印象，下面列出該模型的三個部分： CPU-GPU 渲染管線 基于區塊的渲染 著色器核心架構 在本篇博文中，我們將探討第一個部分，即 CPU-GPU 渲染管線。 同步API，異步執行 務必要了解的一個基本知識是，OpenGL ES API 上應用程序函數調用和這些 API 調用所需渲染運算的執行之間的臨時關系。從應用程序的角度而言，OpenGL ES API被指定為同步 API。應用程序進行一系列的函數調用來設置其下一繪制任務所需的狀態，然后調用 glDraw[1] 函數(通常稱為繪制調用)觸發實際的繪制運算。由于 API是同步的，執行繪制調用后的所有 API 行為都被指定為要像渲染運算已經發生一樣進行，但在幾乎所有硬件加速的 OpenGL ES 實現上，這只是一種由驅動程序堆棧維持的美妙假象。 與繪制調用相似，驅動程序維持的第二個假象是幀末緩沖翻轉。大多數頭一次編寫 OpenGL ES 應用程序的開發人員會告訴你，調用 eglSwapBuffers將交換其應用程序的前緩沖和后緩沖。雖然這在邏輯上是對的，但驅動程序再一次維持了同步性的假象;在幾乎所有平臺上，實際的緩沖交換可能會在很久之后才會發生。 管線化 正如你所想到的，需要創造這一假象的原因在于性能。如果我們強制渲染運算真正同步發生，你就會面臨這樣的尷尬：CPU 忙于創建下一繪制運算的狀態時，GPU 會閑置;GPU 執行渲染時，CPU 會閑置。對于以性能為重的加速器而言，所有這些閑置時間都是絕然不可接受的。 為了去除這一閑置時間，我們使用 OpenGL ES 驅動程序來維持同步渲染行為的假象，而在面紗之后實際是以異步執行的方式處理渲染和幀交換。通過異步運行，我們可以建立一個小小的工作儲備以允許創建一個管線，GPU 從管線的一端處理較舊的工作負載，而 CPU 則負責將新的工作推入另一端。這一方式的優勢在于，只要管線裝滿，就始終有工作在 GPU 上運行，提供最佳的性能。 Mali GPU 管線中的工作單元是以渲染目標為單位進行計劃的，其中渲染目標可能是屏幕緩存或離屏緩存。單個渲染目標通過兩步處理。首先，GPU 為渲染目標中的所有繪制調用處理頂點著色[2]。然后，為整個渲染目標處理片段著色[3]。因此，Mali 的邏輯渲染管線包含三個階段：CPU 處理階段、幾何處理階段，以及片段處理階段。 管線節流 觀察力敏銳的讀者可能已注意到，上圖中片段部分的工作是三個運算中最慢的，被 CPU 和幾何處理階段甩得越來越遠。這種情形并不少見;大多數內容中要著色的片段遠多于頂點，因此片段著色通常是占主導地位的處理運算。 在現實中，最好要盡可能縮短從 CPU 工作結束到幀被渲染之間的延時 – 對最終用戶而言，最讓人煩躁的莫過于在操作觸控屏設備時，其觸控事件輸入和屏幕中數據顯示之間出現數百毫秒的不同步 – 所以，我們不希望等待片段處理階段的工作儲備變得過大。簡而言之，我們需要某種機制來定期減慢 CPU 線程，當管線足夠滿、能夠維持良好性能時停止把工作放入隊列。 這種節流機制通常由主機窗口系統提供，而不是圖形驅動程序本身。例如，在 Android 上，我們只有在知道緩沖方向時才能處理任何繪制運算，因為用戶可能會旋轉其設備，造成幀大小出現變化。SurfaceFlinger— Android 窗口表面管理器 – 可以通過一個簡單方式控制管線深度：當管線中排隊等待渲染的緩沖數量超過 N 個時，拒絕將緩沖返回到應用程序的圖形堆棧。 如果出現這種情形，你就會看到：一旦每一幀達到“N”時 CPU 就會進入閑置狀態，在內部阻止 EGL 或 OpenGL ES API 函數，直到顯示屏消耗完一個待處理緩存，為新的渲染運算空出一個位置。 如果圖形堆棧的運行快于顯示刷新率，同樣的方案也可限制管線緩沖;在這一情形下，內容受到VSYNC限制”并等待垂直空白(VSYNC同步)信號，該信號告訴顯示控制器它可以切換到下一緩沖。如果 GPU 產生幀的速度快于顯示屏顯示幀的速度，那么 SurfaceFlinger 將積累一定數量已經完成渲染但依然需要顯示在屏幕上的緩沖;即使這些緩沖不再是 Mali 管線的一個部分，它們依然算在應用程序進程的 N 幀限制內。 正如上面的管線示意圖所示，如果內容受到VSYNC同步限制，那么會經常出現 CPU 和 GPU 都完全閑置的時段。平臺動態電壓和頻率調節 (DVFS) 通常會在此類情形中嘗試降低當前的工作頻率，以降低電壓和功耗，但由于 DVFS 頻率選擇通常相對粗糙，所以可能會出現一定數量的閑置時間。 小結 本篇博文中，我們探討了 OpenGL ES API 提供的同步假象，以及 API 下實際運行異步渲染管線的原因。 |
