Chromium Graphics: GPU用戶端之間同步機制的原理和實現分析-Part I，chromium-part

Chromium Graphics: GPU用戶端之間同步機制的原理和實現分析-Part I，chromium-part

摘要：Chromium中GPU進程架構允許多個GPU用戶端會同時訪問GPU服務，而GPU用戶端之間可能存在資料依賴關係，因此必須提供一種同步機制保證GPU操作的先後次序。本文討論多進程架構下GPU用戶端之間的同步問題，以及同步點(SyncPoint)機制的基本原理。

GPU進程架構等基本概念

我們知道，Chromium是一個多進程架構的軟體系統。出於安全和穩定性方面的考慮，Chromium有個專門的進程（或者線程）和GPU裝置進行互動，執行GL操作，也就是說，任何一條GL命令都必須經由這個進程處理後才提交給GPU驅動，這個進程就是GPU進程。Renderer進程或者Browser進程必須通過IPC才能與GPU進程互動，告訴GPU進程需要執行哪些GL命令。在這個過程中，Renderer進程或Browser進程是GPU用戶端，而GPU進程本身就是GPU服務端。

GPU用戶端和服務端之間GL命令傳輸是通過命令緩衝區（CommandBuffer）完成的。CommandBuffer是Chromium為解決多進程架構下高效在用戶端和服務端傳輸GL命令而設計的，緩衝區使用共用記憶體儲存GL命令，每條GL命令的命令名和參數都會被序列化為字串儲存在命令列緩衝區中。當用戶端需要將命令緩衝區中的所有GL命令提交給GPU服務端時，用戶端會向服務端發送一條GpuCommandBufferMsg_AsyncFlush訊息，服務端收到這條訊息後會根據指定的位移從CommandBuffer中讀取GL命令並將其還原序列化後再提交給GPU驅動。

Chromium中，頁面的渲染和合成過程都啟用了GPU硬體加速，任何一個要求GPU硬體加速的進程都是GPU進程的用戶端，例如Renderer進程是GPU用戶端，因為它需要請求GPU進程繪製和合成頁面的內容，Browser進程也是GPU用戶端，因為它需要將頁面的內容與地址欄等元素進行最終的合成，並顯示在螢幕上。

給出了GPU用戶端、GPU服務端以及命令緩衝區的基本關係。

GPU用戶端之間可以通過mailbox機制進行texture共用的，簡單的說，mailbox機制就是給每個texture產生唯一標識，並由GPU進程統一管理名標識和texture之間的映射關係，同時這些GPU用戶端屬於同一上下文共用組，因此所有texture資源也是可以共用的。

GPU用戶端之間的同步問題

從上述描述不難看出，GPU進程需要處理來自多個GPU用戶端的請求，並且這些GPU用戶端可能存在紋理(Texture)資料依賴關係。下面以Android平台上渲染WebGL頁面http://get.webgl.org 為例，說明為什麼不同GPU用戶端會存在資料依賴關係。

首先，Browser進程是一個GPU用戶端，它建立了一個Browser端的合成器（Compositor）請求GPU進程將頁面的內容和地址欄等UI元素（如果有）進行最終的合成，並將其渲染到SurfaceView上。Renderer進程也是GPU用戶端，它也會建立一個Renderer端的合成器用於頁面內容的合成，而且這個用戶端中還包含了兩個獨立的3D上下文，一個用於頁面中渲染層的合成，另一個作為WebGL的渲染上下文。

其次，在Android平台上，預設啟用了委託模式(DelegatedRenderer)的渲染器，因此，Renderer端合成器管理的所有GPU資源（包括WebGL）都會通過IPC轉交給Browser端的合成器，再由Browser端合成器對所有的texture進行統一的合成，當最終的合成操作完成之後，Browser端合成器則會通知Renderer端，此時Renderer端的合成器可以安全刪除不再使用的GPU資源。

最後，再來看看WebGL的渲染過程。在硬體加速的頁面渲染機制中，頁面的內容是由多個渲染層(RenderLayer)構成的，每個渲染層的儲存後端對應一個Texture，WebGL正是這樣一個渲染層，它具有一個獨立的Texture儲存後端。在渲染每一幀內容時，Renderer進程會請求GPU進程建立一個新的Texture來存放WebGL的渲染結果，並通過Framebuffer對象將WebGL渲染到這個Texture中。待 WebGL命令完畢後，Renderer端的合成器會將這個Texture以資源形式發送給Browser端的合成器。當Browser端合成器完成WebGL內容的合成之後，會通知Renderer端將這個Texture刪除。

那麼，從上面的描述中可以推斷出整個過程存在哪些問題呢？

第一，Renderer端的合成器和Browser端合成器存在資料依賴關係，是生產者-消費者的關係，即Renderer端的WebGL上下文產生Texture內容，Browser端合成器使用該內容；

第二，WebGL上下文和Browser端合成器存在同步問題。由於所有的GL命令都是在同一線程中執行，包括Browser端合成器和WebGL，而3D上下文是GPU線程的調度基本單位，也就是只有同一個3D上下文中GL命令才能按照順序逐條執行的。一方面，不同GPU用戶端可能運行在不同的進程或者線程中，另一方面，同一GPU用戶端的不同3D上下文可能運行在不同的線程中，例如Renderer進程的合成器運行在一個單獨的線程中，而WebGL運行在Renderer進程的主線程中。顯然，不同3D上下文中GL命令執行次序是不分先後的，這裡就引申出一個問題，對於WebGL頁面渲染而言，必須保證以下這兩個要求：

• 當WebGL內容相關的GL命令執行完畢後，Browser端合成器才能使用；
• 當Browser端合成器使用完WebGL的Texture後，WebGL上下文才能安全刪除；

否則Browser合成器使用的texture將會是不完整的。這就是GPU用戶端之間的同步問題，接下來將重點討論Chromium是如何解決這個問題的。

同步點機制的基本原理

Chromium通過GL擴充介面設計了一套同步機制解決不同GPU用戶端之間的同步問題，它必須滿足兩個條件：

第一，上下文A可以等待上下文B執行完一組GL命令後再執行內容A中後續的GL命令；

第二，上下文A中的這種等待必須是非阻塞的，也就是說GPU用戶端代碼的執行不能被阻塞；

根據gpu/gles2/extensions/GL_CHROMIUM_sync_point.txt檔案所述，同步點機制定義了兩個特定於Chromium的GL擴充介面：

        uint InsertSyncPointCHROMIUM()        void WaitSyncPointCHROMIUM(uint sync_point)

InsertSyncPointCHROMIUM在當前上下文中建立一個同步點並將其插入到命令流中，這個同步點起到一個防護牆的作用，當這個同步點之前的命令都已經提交到伺服器，或者上下文被銷毀時，會向該同步點發個訊號。返回同步點的標識符。收到訊號後，這個同步點會被刪除點。在同一個伺服器上同步點標識符在所有上下文中是唯一的，包括同一共用組的上下文。

WaitSyncPointCHROMIUM導致當前上下文暫停提交GL命令，直到指定同步點收到訊號，被實現為服務端的等待。參數sync_point為InsertSyncPointCHROMIUM返回的同步點標識符。如果sync_point參數無效，這個命令相當於no-op操作並且不會報錯。

以上文檔化的描述讀起來有些晦澀難懂，下面通過一個簡化的例子更直觀地說明SyncPoint在Chromium中的運行原理：

 

假設有兩個上下文A和B，它們可能在不同的GPU用戶端中，但屬於同一個共用組（ShareGroup），GPU用戶端代碼中通過調用InsertSyncPointCHROMIUM在上下文A的命令流中插入一個同步點sp，而在上下文B中，調用WaitSyncPointCHROMIUM等待同步點sp，最終在GPU服務端執行GL命令的順序為，只有當上下文A中同步點sp之前的GL命令A1，A2和A3執行完畢後，才會執行內容B中的GL命令B3。

更進一步地說，上下文B中調用WaitSyncPointCHROMIUM(sp)，實際上是指示GPU服務端停止向GPU裝置提交上下文B後續的GL命令，取而代之的是：

• 如果此時上下文A的同步點sp之前的GL命令都已經執行完畢，即同步點sp收到訊號，已經從被刪除了，那麼可以忽略WaitSyncPointCHROMIUM了，繼續執行內容B中後續的GL命令；
• 如果此時上下文A的同步點sp之前的GL命令尚未執行，那麼取而代之的是將等待上下文A中sp點之前的GL命令執行完畢。這個等待發生在GPU服務端的，不會阻塞GPU用戶端後續代碼的運行（如Renderer進行的運行）。

綜上所述，同步點機制允許用戶端設定不同上下文之間GL命令執行的次序，上下文B等待上下文A的同步點實際上是保證A中同步點之前的命令在B中後續命令之前執行。

未完待續...下節將從Chromium原始碼中解讀同步點機制是如何?的