Chrome 渲染流水線演化的未來

前段時間我寫了一篇文章瀏覽器渲染流水線解析與網頁動畫性能優化，對目前 60 左右版本的 Chrome 的渲染流水線進行解析，文末也討論了當前渲染流水線的一些不足和未來演化的方向。

當前的渲染流水線過於複雜和冗長，特別是對於非合成器動畫來說，過多的線程/進程間交互增加了不少額外開銷，非同步光柵化的機制也是有利於合成器動畫而不利於非合成器動畫。而未來的演化理應需要簡化渲染流水線，減少線程/進程間交互，避免非必要的額外開銷，光柵化和合成不再像現在一樣涇渭分明，渲染流水線可以支持更靈活和動態自適應的圖層化和光柵化策略，根據硬體的能力和性能，還有頁面的繪製特徵採取不同的圖層化和光柵化方式，從而最大化頁面的動畫性能。

最近通過閱讀 Chrome 官方的一些文檔，對 Chrome 渲染流水線未來演化的一些細節也有了更多認識。本文主要針對最近一次 Blinkon 上的演講 What is Viz: The Future of Chrome Compositing 進行解讀（如果該網址無法訪問，可以從作者的 Github 上下載完整的 Slides），回饋對此感興趣的讀者。

FBI WARNING

個人解讀不保證絕對正確

1 Servicification

Chrome 渲染流水線的演化是在 Chrome 整個系統架構演化的大背景下發生的，官方稱這個過程為 Servicification，釋義來自於維基百科：

Servicification is 「the migration from monolithic legacy applications into service-based components」

對 Chrome 來說，就是：

Splitting a monolithic Chrome browser up into components.

也就是說 Chrome 整體架構會朝向現代 OS 所採用的 SOA (Services Oriented Architecture) 方向發展，原來的各種模塊會被重構成獨立的 Services，每個 Service 都可以運行在獨立進程，訪問 Services 必須通過定義好的介面，通過 IPC 進行通訊，從而構建一個更內聚，松耦合，易於維護和擴展的系統，更好實現 Chrome 的目標：

• Speed
• Simplicity
• Security
• Stability

Chrome 的渲染相關模塊最終會重構成兩個 Services，一個負責非網頁部分繪製的 UI Service，包括瀏覽器的 UI 界面，Chrome OS 的 GUI 界面等；一個負責網頁部分繪製的 Service，也就是本文主要討論的 Viz。

Chrome 整個系統架構演化這個題目太過龐大，本文不再過多討論，感興趣的讀者可以閱讀官方的這篇文檔 —— Chrome Service Model。

2 Viz

Viz 是 Visuals 的簡寫，按照規劃：

1. GPU 進程被改造成 Viz 進程，用於運行 Viz Service；
2. 分布在其它進程的跟渲染有關的光柵化，多級合成器等，最終都會被整合到 Viz Service，統一運行在 Viz 進程；

最終要達成的目標：

1. 實現 Chrome Servicification 的架構目標，Service 內部更內聚，跟外部的關係更松耦合；
2. 光柵化，合成，GPU 調用等全部彙集在同一個 Service 內部，統一在同一個進程，使得 Chrome 可以對渲染流水線進行重組和簡化，減少不必要的開銷，提高整體效率；

上圖顯示了 Chrome 當前的渲染流水線：

1. GPU 進程的用途是實現對 GPU 的虛擬化封裝，其它進程可以通過 Command Buffer（可以看做是 Chrome 提供的一個 Virtual GL Context）跨進程地訪問 GPU，Command Buffer 通過支持跨進程，帶來了更好的安全性和健壯性，但是也引入了一定的額外開銷；
2. 光柵化和 Layer Compositor 運行在 Renderer 進程，光柵化器（GPU 光柵化）通過 Command Buffer 跨進程訪問 GPU；
3. Display Compositor 運行在 Browser 進程，同樣通過 Command Buffer 跨進程訪問 GPU；

Viz 改造是逐步進行的，每一階段會實現一些新特性，本文後續的部分會對這些新特性的內容進行介紹。

2.1 Tadpole - Direct Compositing

Direct Compositing 實際包含前後兩個步驟：

1. 首先是 Display Compositor 要從 Browser 進程遷移到 Viz 進程（原 GPU 進程）；
2. 然後 Display Compositor 原來使用的 GLRenderer 會替換成新的 SkiaRenderer，SkiaRenderer 直接使用 Native GL 而不是通過 Command Buffer 封裝的 Virtual GL；

Direct Compositing 預計能帶來 10% - 15% 左右的性能提升，減少了進程間交互和 Command Buffer 帶來的額外開銷。在這個過程中 Renderer 進程保持不變。

2.2 OOP Rasterization

OOP 是 Out of Process 的縮寫，所謂 OOP Rasterization 就是將光柵化從 Renderer 進程遷移到 Viz 進程。

原來的光柵化器（GPU 光柵化）運行在 Renderer 進程，它將 2D 繪圖指令轉換成 GL 繪圖指令通過 Command Buffer 交給 GPU 進程運行。OOP Rasterization 後，位於 Renderer 進程的 Layer Compositor 需要支持 2D 繪圖指令的序列化和反序列化，將 2D 繪圖指令傳遞到 Viz 進程執行。

OOP Rasterization 處於跟 Direct Compositing 並行開發的階段，並最終會進行融合。融合後的結果如上圖，光柵化器（GPU 光柵化）和 Display Compositor 同樣使用 SkiaRenderer，直接調用 Native GL 而不是通過 Command Buffer 封裝的 Virtual GL。

2.3 Vulkan

Command Buffer 基本上是以 GL 為模板設計出來的，API 跟 GLES 也保持一一對應，這也意味著很難讓 Command Buffer 同時也支持 Vulkan。Chrome 引入對 Vulkan 的支持主要是通過 Skia，SkiaRenderer 或者 Skia Ganesh Compositor（抱歉我也搞不清到底哪個會是最後官方的稱謂）會同時支持使用 GL 或者 Vulkan 作為 Backend，根據設備的硬體能力進行選擇。

預計使用 Vulkan 比起使用 GL 會帶來 10 - 15% 的性能提升。

2.3.1 WebGL

對於 WebGL 來說，為了保證在 Renderer 進程使用 GPU 的安全性和健壯性，WebGL 對 GL 的調用還是一樣要通過 Command Buffer。後端的實現可能有兩種方式，一種是後端仍然在一個獨立的 GL Context 上使用 GL，然後 WebGL 繪製的 FrameBuffer 通過平台相關的 API share 到 Vulkan Context；另外一種是通過 Angle for Vulkan (aka Vangle) 將 GL 指令轉換成 Vulkan 指令在 Vulkan Context 上運行，個人猜測移動平台上多半是前者。

2.4 Salamander - Central Layerization

Salamander 是目前規劃的 Viz 改造的最後階段：

1. Layer Compositor 從 Renderer 進程遷移到 Viz 進程，並和 Display Compositor 融合成 Unified Compositor；
2. Renderer 發送給 Viz 的數據只包括每一個排版對象的繪圖指令，和攜帶圖層數據的 Property Trees，Unified Compositor 根據這些數據和其它信息來決定最終的圖層化策略；
3. OOPIF 的繪製得到更好的支持，避免不必要的光柵化和合成；

雖然官方的文檔沒有說明，但是個人覺得在這裡 Unified Compositor 可以根據需要選擇不同的光柵化策略，比如為個別圖層分配 Offscreen Buffer，採用 ASync 或者 On Demand Rasterization 的光柵化策略；而另外一些圖層則不分配 Buffer，採用 Direct Rasterization 的光柵化策略；

3 Summary

3.1 Viz Status

正在進行中

• Tadpole: relocate the DisplayCompositor to Viz in 66
• OOP Rasterization in Viz Q2 2018
• SkiaRenderer in 67

2018 Q3 之後開始

• Vulkan graphics
• Salamander: central layerization

整個過程還是相當漫長，目前有明確的版本規劃的只是 67 的 Direct Composting，其它只有大概的時間規劃，還沒有明確會在哪個版本 Landing。

3.2 Viz Take-aways

從兩個角度思考 Viz：

1. Chrome 圖形子系統的 Servicification 過程；
2. 更好的 GPU 進程；

Viz 從下面三個方面帶來渲染性能的提升：

1. 10 - 15% 的性能提升來自於移除不必要的 Command Buffer 的使用；
2. 10 - 15% 的性能提升來自於對 Vulkan 的支持；
3. 對 OOPIF 繪製的更好支持，避免不必要的光柵化和合成；

推薦閱讀：