Chrome 渲染流水線演化的將來

摘要：

前段時間我寫了一篇文章瀏覽器渲染流水線解析與網頁動畫性能優化，對目前 60 左右版本的 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 繪製的更好支持，避免沒必要要的光柵化和合成；

做者： 小扎zack

原文地址