Linux Graphics 周刊（第 1 期）

(2020.8.10 ~ 2020.8.16)

DRM

1. 徹底廢棄 drm_driver 中的 prime callbacks，全面啟用 GEM Object functions

從 kernel 4.19 開始，DRM 架構引入了 shmem GEM 後端，随該 patch 一同合入的還有

drm_gem_object_funcs

結構體。該結構體的引入，極大的統一了 GEM Prime 接口的管理。以前，凡是和 prime 相關的接口都是放在

drm_driver

結構體中的，這使得 drm_driver 結構體變得越來越臃腫，架構調用也顯得比較淩亂。而引入 drm_gem_object_funcs 之後，隻需要通過 drm gem object 就可以調用相關的回調函數，而無需通路 drm_driver 指針。這才真正展現了 kernel 的面向對象思想，以前 gem object 中隻有資料，沒有方法（即回調函數），現在的 gem object 成了一個鮮活的對象，它既有資料又有方法，拿到 gem object 就可以完成所有與 GEM 相關的操作，非常友善，且可讀性強。

雖然從 2018 年就合入了 drm_gem_object_funcs 的功能，但大部分 drm 驅動仍然保持着原有的 drm_driver prime 接口，drm_gem_object_funcs 的普及率并不高。如今，是時候該對這些驅動進行清理了。Thomas Zimmermann（ drm-misc Maintainer, SUSE）為我們做了這件事，他總共提了 20 筆 patch，其中第 1~ 19 筆 patch 是專門用來清理各個 drm 裝置驅動的，第 20 筆 patch 則是徹底删除 drm_driver 中 gem prime 相關 callbacks 的。

更多詳細内容，請查閱 dri-devel 郵件清單：[PATCH 00/20] Convert all remaining drivers to GEM object functions

2. 為 GEM vmap 添加 I/O memory 的支援

drm prime exporter 中有一個 vmap 接口，專門用于将後端記憶體映射到一片連續的虛拟位址空間上（kernel 空間），友善在 kernel 空間使用 CPU 去通路這段記憶體。但如果要通路的實體記憶體是在 IO 端口上呢？目前的接口對于 ARM 平台來說都沒有什麼大問題，通路 IO 位址空間和通路普通的記憶體沒有什麼差別。但對于 sparc64 或 X86 這種架構的平台來說可能就不那麼友善了，衆所周知，在這類平台上如果要通路 IO 端口位址空間，需要使用專門的 IO 指令，如 X86 上的 IN 和 OUT。對于這類平台，就需要對 vmap 接口進行 hack 了，否則傳回的 IO 位址被拿去當 CPU 位址使用可就麻煩了。

為了解決 bochs drm 驅動中的 sparc64 IO memory 映射問題，Thomas Zimmermann（drm-misc maintainer, SUSE）新增了

drm_gem_membuf

結構體，用于儲存 vmap 傳回的位址，不過該位址不再是簡單的 CPU 指針，而是 CPU 位址和 IO 位址的聯合體，通過 is_iomem 變量來進行區分。同時，所有 gem prime vmap 接口傳回的位址都被修改成了 drm_gem_membuf 結構體指針，以此來相容 IO memory 的映射。

更多詳細内容，請查閱 dri-devel 郵件清單：[RFC][PATCH v2 0/4] Support GEM object mappings from I/O memory

3. dma-heap：添加 system-uncached HEAP

ION 是 Android 系統下專用于配置設定 Graphic Buffer 的記憶體配置設定器，它是基于 DMA-BUF 實作的，可以在多個裝置之間實作 buffer 共享。不過它的代碼一直存放在 staging 目錄下，再過幾年可能就不複存在了，而 dma-heap 則是專門用來取代 ION 的。用過 ION 的同學都知道，ION 在 SYSTEM_HEAP 上配置設定記憶體時，既可以配置設定帶 cache 的 buffer，也可以申請不帶 cache 的 buffer，這個過程是通過傳入

ION_FLAG_CACHED

标志位來實作的。

而現有的 dma-heap 功能還比較單一，隻支援 SYSTEM HEAP（實體非連續 buffer） 和 CMA HEAP（實體連續 buffer），而且 SYSTEM HEAP 預設隻支援帶 Cached 的 buffer，不帶 cache 的 buffer 目前還不支援。通常，隻有 CPU 需要參與通路的 buffer 才需要帶 cached，這樣可以加快 CPU 的通路速度，但是在 CPU 和 DMA 裝置之間共享記憶體時，需要來回刷 Cache，這會增加系統開銷。不帶 cached 的 buffer 則通常隻用于 DMA 裝置之間的 buffer 共享，是以省去了 Cache 同步所帶來的額外開銷，提高了裝置之間的通路效率。

正是基于以上原因，John Stultz（dma-heap maintainer, Linaro）給 dma-heap 送出了 system-uncached heap 的 patch，這樣應用程式就可以申請不帶 cache 的 buffer 了（預設為 writecombine），極大的提高了 DMA 裝置通路 buffer 的效率。

更多詳細内容，請查閱 dri-devel 郵件清單：[RFC][PATCH v2 2/2] dma-heap: Add a system-uncached heap

4. DMA Heap vs GEM

DMA Heap 是用來替代 ION 的記憶體配置設定器，主要用于多媒體裝置的 Graphic Buffer 配置設定。而 DRM 下的 GEM 則是專用于 Display 和 GPU 顯存相關的 buffer 配置設定。二者從功能上來講，都是 buffer 配置設定，且都能将所配置設定的 buffer 轉換成 dma-buf fd 進行裝置間的共享。這就給部分開發者帶來了困惑，如 Mikko Perttunen 就在社群表達了自己的疑惑：

他認為，現今的 dma-heap 已經能很好的滿足 TegraDRM 記憶體配置設定需求，可以完全抛棄傳統的 GEM 架構，不用再實作驅動自定義的 GEM IOCTL 記憶體配置設定接口，直接使用 dma-heap 來代替就可以了。但是他又覺得頭疼的是，dma-heap 相比 GEM 有一個劣勢，就是 dma-heap 所配置設定的 buffer 隻能以 fd 的形式導出給上層應用。大家都知道，fd 屬于程序資源，每個程序的 fd 總數是有限制的（一般最大 1024 個），一旦應用程式的 fd 被用盡，則無法再擷取到 dma-buf fd，即無法通過 dma-heap 配置設定記憶體。而 DRM GEM 配置設定記憶體時，直接傳回給應用程式的是 GEM OBJ ID，而不是 dma-buf fd，是以 GEM 不會有這類風險。是以他的問題是：dma-heap 在 kernel 中到底扮演着什麼樣的角色？如果 dma-heap 的最終目的是成為一個通用的多媒體 buffer 配置設定器，那麼上面提到的 fd 限制問題是否應該被解決掉？還是說将該問題留給應用程式自己去處理？

對于該問題，Daniel Vetter（drm-misc Maintainer, Intel） 的回答是：目前沒人知道答案。不過他認為，dma-heap 隻是個可以跨裝置共享的記憶體配置設定器，配置設定出來的 dma-buf 主要用于在多個裝置之間共享，是以它更側重于“共享”二字。而 GEM 則是專用于配置設定具有硬體加速功能的 buffer（如 GPU 顯存、或特殊位址的 memory），該 buffer 可以給其他裝置共享，也可以自己私有通路，是以它更側重于“專用”二字。是以他并不認為 dma-heap 可以替代 GEM，而且對于 TegraDRM，明明有現成的 GEM IOCTL 接口，為什麼非要用 dma-heap 呢？

而 John Stultz （dma-heap maintainer, Linaro）的回答似乎有點偏題，他并沒有直接回答該問題，而是提到了另一個問題：我們是否需要給 dma-heap 添加 in-kernel use 的接口？因為他發現，有的驅動想直接把 dma-heap 作為自己 buffer 配置設定的後端配置設定器，但是 dma-heap 又沒有提供以 dma-buf 指針作為傳回值的接口，使得它們不得不重寫一套和 dma-heap 重複的 exporter 代碼。他在想 Mikko 是不是也是有類似的需求，如果是的話，他們可以進一步探讨 dma-heap 新增 in-kernel use 接口的可能性。但是站在架構層的角度考慮，他認為 buffer 配置設定還是應該由應用層來發起，而不應該由 kernel 層發起，因為隻有應用程式才最清楚它所需要的 buffer 将傳遞給哪個裝置，是以才能将更為準确的 buffer 屬性傳給 dma-heap 驅動。

更多詳細内容，請查閱 dri-devel 郵件清單：Role of DMA Heaps vs GEM in allocation

5. dma-buf: 為每個程序添加 buffer 使用狀态的 ftrace 資訊

Kalesh Singh（Google）為 dma-buf 添加了 ftrace 跟蹤資訊，可用于跟蹤每個程序對 dma-buf 的配置設定/釋放/mmap/munmap操作。這對于系統面臨大量記憶體使用壓力的情況，能提供有效的性能分析方法。

更多詳細内容，請查閱 dri-devel 郵件清單：[PATCH 0/2] Per process tracking of dma buffers

6. backlight: 代碼優化，新增宏定義及操作接口

Sam Ravnborg（drm-misc maintainer）為簡化 backlight 驅動編寫，新增了 4 個宏定義和 5 個 set/get 輔助接口：

宏定義：

• BACKLIGHT_PROPS

• DECLARE_BACKLIGHT_INIT_RAW

• DECLARE_BACKLIGHT_INIT_PLATFORM

• DECLARE_BACKLIGHT_INIT_FIRMWARE

通過上面的宏定義，我們可以在 backlight 驅動中簡化背光初始化的參數。

set/get helper:

• backlight_get_actual_brightness

• backlight_get_max_brightness

• backlight_set_brightness

• backlight_set_power_on

• backlight_set_power_off

如果沒有這些接口，我們隻能通過 bd->props.xxx 來通路，每次還要做空指針判斷，代碼繁瑣。現在有了這些 helper 接口，我們的代碼就會幹淨許多。

更多詳細内容，請查閱 dri-devel 郵件清單：[RFC PATCH v1 0/22] backlight: add init macros and accessors

7. Huawei Hikey970 DRM/KMS 驅動 Upstreaming

Hikey970 是華為 2018 年推出的一款開源 96Board，基于海思麒麟970 SoC，CPU 為 4 核 A73 + 4 核 A53，GPU 采用 ARM Mali-G72 MP12，性能強勁，主要用于 AI 高性能計算。

前不久 Mauro Carvalho Chehab（華為？）向社群送出了 Hikey970 的 DRM/KMS 驅動，該驅動來源于 Linaro Hikey 官方 kernel 倉庫，目前該驅動顯示功能還存在一定 bug (如休眠喚醒後顯示器将無法恢複到之前的時鐘頻率)，不過這并不影響 Mauro 的 upstreaming 計劃。目前主要是接受社群人員的 comment，好做進一步調整，預計離真正 merge 還有很長一段路要走。

更多詳細内容，請查閱 dri-devel 郵件清單：DRM/KMS experimental drivers for HiKey 970

以下内容因為工作太忙，沒來得及詳細介紹，大家就直接通路原連結吧。

Mesa

AMD R600 骨灰級顯示卡 Gallium3D 驅動新增 Computer Shader 功能

詳情：R600 Gallium3D Now Has Compute Shaders Working With NIR

Wayland

1. [ANNOUNCE] weston 8.0.92

2. [ANNOUNCE] libinput 1.16.1

3. RFC: libei - emulated input in Wayland compositors

其他

1. Fedora’s FESCo Approves Using DXVK As Their Default Wine Direct3D Back-End

2. What is PVRTune Complete?