一文搞懂顯示技術的底層框架

PC 上 DPU 是嵌入在顯卡上，不管是獨立顯卡還是集成顯卡都是如此。由於 GPU 能力越來越強，DPU 目前基本是附贈的功能，但從歷史來看，GPU 纔是後有的新鮮之物，最早的只有 DPU，從最早的 Framebuffer 機制就能看出，DRM 框架中最早版本中也是不存在 GPU 的代碼。

DPU 最簡單的功能便是將 Frambuffer 數據輸出到顯示設備上去，而 Framebuffer 的來源也都是來自於 CPU 的軟件繪製，而非 GPU 繪製。

上圖沒有給我們很大啓發，因爲這離我們現代的 DPU 設計差別太遠。

1. DPU 與 GPU 的耦合是歷史產物，完全可以獨立出來

【DPU 用於控制端，GPU 用於內容端】

通過 Linux 的 dri 顯示框架，也能看出 KMS 的相對獨立性，對應於系統側的 composer，而 drm 則在於內容相關的應用側。對於 Android 系統也是一樣的，GPU 對應於 drm（不過高通與 mali 並沒有遵循這個開源 drm 框架）是用來繪製的，屬於應用端的進程；而 DPU 對應於 KMS，運行於服務端，可以認爲在 SurfaceFlinger（composer）中，開機就會初始化，然後保持不變，兩者的分離更加徹底。

PC 上 Linux 與移動端 Android 的不同

PC 上耦合還是非常強的，DPU 與 GPU 共享顯存，代碼也放在一個文件裏，Buffer 管理（GEM/TTM）自然是互通的，linux 中默認代碼是合併一塊的，這是歷史遺留問題——Andriod 則不同，天生就是分離的，而 ION 是 Android 分配 buffer 的標準。

Linux 平臺：我們拿高通 adreno 的 Linux 開源代碼來看，系統將 DPU 與 GPU 合併在一個文件夾下: drivers/gpu/drm/msm，功能基本也大體是分開的，比如 GPU 相關的爲：adreno、msm_gpu.c，msm_ringbuffer.c，比如 DPU 相關的爲 disp，edp，hdmi 等。但仍然有一部分代碼是耦合在一起的，比如 msm_gem.c, mem_drv.c。GPU 命令還是使用 drm 標準的或定製的命令。

對於 GPU 來說，UMD 使用的是 mesa（高通並沒有官方 linux 的支持）

Android 平臺：高通官方代碼則在兩個完全不同的倉庫，不存在任何代碼的共享，GPU 放在 drivers/gpu/msm，配置的是 KGSL，DPU 則是不開源的私有庫（OEM 廠商可以拿到）。這也說明兩者邏輯上並不存在那麼緊密的聯繫，也就是傳個 framebuffer。

對於 GPU 來說，UMD 是 libGLES_xx.so(包含 GL 和 EGL)，並沒有 GEM 和 DRM 那套東西，完全閉源，OEM 也拿不到源碼。

GPU 與 DPU 完全可以採用不同的廠商，但通常也是一家的，原因何在呢？

Buffer 共享更高效：雖然 buffer 共享是通過 ion，但是爲了節省 DDR 帶寬，通常會將共享的 buffer 壓縮，比如 Arm 的 AFBC，高通的 UBWC。

如果使用不同的廠家，其實也能做到這一點，比如對於 ARM，如今 mali gpu 還是廣泛被使用，但 mali dpu 已經少有人用了，那就附贈一個 AFBC Decode 模塊，如下圖。（高通並沒有放開這個限制）

DPU 的基本功能應該有哪些呢？

DPU 的設計相比 GPU 來說還是簡單的，在於其功能的固定性，不可編程，其基本功能大約有 2 個。

• 1）2D 加速（縮放，合成）

最早的 linux 代碼還能看出痕跡，一開始 2D 加速功能都是使用 CPU；後面 2D 加速開始使用 GPU 來實現。到 Android 系統後，則由 GPU 專門的 2D 模塊來實現（甚至會配置爲雙 GPU，其中一個 GPU 只做 2D 加速），然後專門的 DPU 出現代替了 GPU 的 2D 模塊（後面 GPU 再沒有專門的 2D 模塊，因爲 2D 本來就是 3D 的子集，雖然專門設計的 2D 模塊效率會高一點，但也沒有 DPU 效果高，所以逐漸淘汰）。

• 2）vout 的管理（連接 LCD，HDMI 等設備）。

下面給出 DPU 的一個基本設計原型，這包含 4 個部分。

2. DPU 的原型設計

2.1【DPU 的四大組成部分】

這是 2013 年的 DPU 設計圖，當年 Android 發佈了升級最大的 4.4（也許是最成功的一代）。從下圖可以看出 DPU 的設計大體分爲四部分：

1）Source Surface Pipes（Pipe 也稱 overlay，後面不再區分）: 支持 4 個 overlay 通道（V1-V4），支持 RGBX，YUV 等多個格式，縮放比例（1/4 - 4），且每一個 layer 都支持 alpha 通道，

• C1、C2 是鼠標層，對於 PC 來說很重要，但對於手機來說基本沒人使用。

• 當時還不支持旋轉；

• 支持 4 個 layer 的 alpha blending，在當時還是比較奢侈的，比如監控就沒必要這樣設計了，更離譜的有的設計了 16 個 layer 看着很唬人，但支持 alpha 只有 1 個，也沒有任何用處，對於 Android 系統來說 alpha 的 layer 特別多。

2）Blender： 支持 2 個 Blender，對應於 2 個 Path（除了 LCD 外，對應於 DP 或 HDMI 投屏）；

3）Destination surface post-processor：支持 dither，gamma 調整；目前的趨勢是這部分越來越重要。

4）Display Interface：支持最多 2 路同時的輸出設備（物理顯示設備，虛擬顯示設備不需要實際的輸出設備）；支持 LVDS，DSI，CVBS，HDMI 等顯示設備；

DPU 更細節的圖如下：

如果放在 Android 系統中，我們來看一個 HDR 視頻的播放流程的話，則能更好的看出這 4 個部分。

2.2【KSM 與 DPU】

其實這張圖也和我們常見的 DRM 的 KSM 框架圖非常契合，也就是說 KSM 與 DPU 功能幾乎等同：

• Source Surface Pipes：每個 overlay 對應一個 Plane，每個 ovelay 中都有一個 DRM Framebuffer；在 dumpsys SurfaceFlinger 的時候，每個 Layer 就是一個 overlay，一個 DRM Framebuffer。

-----------------------------------------------------------------------------------------------------------------------------------------------
 Layer name
           Z |  Window Type |  Layer Class |  Comp Type |  Transform |   Disp Frame (LTRB) |          Source Crop (LTRB) |     Frame Rate (Explicit) [Focused]
-----------------------------------------------------------------------------------------------------------------------------------------------
 com.android.systemui.ImageWallpaper#0
  rel      0 |         2013 |            0 |     DEVICE |          0 |    0    0 1080 2400 |    0.0    0.0 1080.0 2400.0 |                              [ ]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 com.miui.home/com.miui.home.launcher.Launcher#0
  rel      0 |            1 |            0 |     DEVICE |          0 |    0    0 1080 2400 |    0.0    0.0 1080.0 2400.0 |                              [*]

• CRTC：對應於一個 Path，每個 Path 至少有一個 Blender，DSPP 也在此處（如下圖）；所有的 layer 都會做 alpha blending，輸出到一個顯示通路，通常格式爲 RGB24 和 RGB30（10bit），也就是顯示在屏幕上的內容。

• Display Interface：Encoder，Connector 是與顯示設備相關的；最終這個 RGB24 的數據會通過 MIPI、DP 傳給顯示設備，這些協議相關的實現也在 DPU 模塊內完成。

3. DPU 的最新設計

3.1【Source Suface Pipes or Overlays】

1）Pipes（也有叫 overlays）一般分爲兩種：（這也不能叫趨勢，高通從一開始就有這兩種）

• 一種支持縮放、旋轉，銳化等複雜功能的 Video overlay（當然，video overlay 可以適用於任何 layer，video 只是一個稱呼，更適用於遊戲和視頻）；這裏的縮放，銳化是單 layer 的，與後面的整個屏幕的縮放不同。

• 一種簡單功能的 Graphic overlay；支持格式轉換，也支持 alpha；

2）支持輸入的分辨率更大，比如支持 4K 的輸入，這需要更高的 DPU 頻率；

3）隨着 XR（AR、VR）設備的出現，目前單眼 4k 已經出現（DPU 就要支持 8K 的輸入），這樣帶寬壓力太大，所以目前的做法通常並不是直接 4K 的輸入，而是切分成 2 個 2k（當然這樣可用的 layer 就會減小一半），這就是 Split 功能；（這也不是新功能，因爲很多年前 4k 視頻就出現了）。

4）支持旋轉，主要用於視頻播放，其他場景基本用不上，GPU 會預旋轉。（mali dp 650 支持這個就不好，主要帶寬影響太大，從 kernel 開源代碼看，dp650 後，mali 似乎便沒有更新）

5）pipe 越來愈多，比如 8 個，16 個（基本也不會比這更多了）

• 對於手機至少需要 6 個：1. Main activity (2 layers); 2. status and navi bar (2 layers) 3. round cornor(2 layers，高通針對 round cornor 這種永遠不會變化的區域也有優化）；

• 對於應用於電視的 Box 則要考慮縮放，每個 layer 都會被縮放（所以需要一個 dest 的縮放，而非 source）

6）支持壓縮格式（UBWC 或 AFBC）；減小內存帶寬，特別是與 GPU 的交互帶寬。

小結：這些技術都出現很多年了，也看不出未來變化的趨勢，除了第三點，因爲 XR 對於分辨率的追求仍沒有到頭，單眼 8K 也會到來，這樣 DPU 要支持 16K 的輸入，這個帶寬壓力太大了（特別是在 scale down 的時候），即使切成 2 個 8K，壓力仍然很大，所以未來是不是搞 2 個 DPU 出來也未可知。

3.2【Blender】

1）合成 layer 越來愈多，比如支持 10 個 layer 的合成（大部分 layer 其實不會互相疊加）；

2）合成 path 越來愈多，比如支持 4 個（同時使用 3 個的場景已經非常罕見）

• WFD（虛擬顯示設備）也算是一個 path，對於 XR 來說每個 2D 應用都是通過 wfd 來實現的，而 WFD 是 DPU 的 writeback 功能實現的，而 writeback 功能一般也只支持一個 path，如果有多個 wfd，則只能藉助 GPU 來實現了。

• 如果未來有發展，便在於是否增加 Writeback 的 path，如果這樣不合算，則需要考慮只採用一個虛擬顯示設備，所有的 2D 應用都放在此處。

3）支持 3D 功能；（可以區分左右眼，因爲 3D 功能是很多年前便普及的了，所以不是新技術）

4）Dim layer：Android 上的常用場景，作爲漸變色，只有灰度值的變化，其他不變；

• 如果大家對於 OLED 屏幕上的 DC 調光有了解，便會知道，Oppo 最初的方案便是增加一個 dim layer，然後調整這個灰度值去讓屏幕顯得沒有那麼亮，從而避免 PWM 調光。

5）Background color：對於單色圖片，也有一些優化方案。

小結：對於 4 和 5，完全是根據應用場景增加的優化方案，爲了節省功耗，也算是一點點摳了。未來 XR 的發展，可能會針對 Writeback 功能做進一步優化；

3.3【Destination surface post-processor】

最開始後處理還只是 dither、gamma 校正、還有亮度、對比度、飽和度調整這些功能，在四個模塊中並不重要，但卻是近幾年發展最快的一個模塊了。現在旗艦手機很多用上了獨立顯示芯片 PixelWorks（後面簡稱 PW），宣傳的功能便是：MEMC、HDR、陽光屏（CABL）、護眼模式、Demura、超分；這些功能高通都有，全放在自己的後處理中。

1） 超分與銳化

這裏的超分指的是 Destination Scaler，是對整個屏幕數據做的，與前面的 Source pipe 的針對 layer 的超分是不同的，雖然算法是一樣的。

目前平臺幾乎都不再使用簡單的雙線性插值，而是自己的算法，但目前仍是基於單幀的技術，雖然 MTK 宣稱已經支持 AI 超分，但效果並沒有讓大家覺得特別亮眼。

PC 上的有英偉達的 AI 超分 DLSS、AMD 的傳統超分 FSR，在網上反映都還比較不錯，但放在手機上要麼功耗高，要麼在手機上這種高 PPI 的應用場景，超分的優勢就沒那麼大了。（在 PC 上表現良好的 FSR 超分算法在手機上效果真的是不好）

隨着 XR 對於分辨率越來越高，所以這個需求還會繼續發展，也是未來的一個發展方向。

2）支持 HDR，SDR to HDR，都是基本操作。

3）亮度調整：區別於 Android 根據環境光調整，主要是基於內容的背光調整算法。可以區分爲 indoor 和 outdoor。Indoor 光線不強，主要由 CABL 和 FOSS，其中分別針對 LCD 和 OLED 屏幕；outdoor 則使用 ARM 的陽光屏技術，當然高通在後面採用了自己的 Local Tone Mapper 策略（既可以用於 indoor，也可以用於 outdoor）替換了 ARM 的陽光屏技術，主要拉昇圖像暗處細節，也不能讓高亮的地方出現過飽和。

4）MEMC：電視上的標配，目前手機上也都是放在視頻上，是 PW 最開始引入手機上最重要的原因，通過插幀實現 30 幀都 60 幀視頻的流暢。

5）demura：oled 上的必備流程

小結：同樣工作放在 DPU 中處理功耗也會低一點，PW 是放在後處理後的 interface 模塊，所以 PW 去做功耗則會高一點；如果 DDIC 去做，則功耗會更高一點，越靠前則功耗更低。不僅在於流程，還在於製程，所以 PW 存在的價值在於其算法能力，是否能超過高通或 MTK。

3.4【Display Interface】

東西很多，不再一一列舉（後面專門講下 mipi），可見未來的發展還在於 XR。

4. 總結

DPU 分爲 4 部分，功能已經比較穩定：其中顯示後處理是以後升級的重點（其中超分與銳化又是優化的重點），同樣的功能，相比獨立顯示芯片 PW 或 DDIC 去做有更好的功耗；

XR 會極大左右 DPU 的發展：無論是分辨率帶來的帶寬壓力，還是最新的注視點傳輸這樣的技術，都需要 DPU 做出較大改變。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ugzzV2g0pyyfOkUMCJmtCQ