Linux Graphics 周刊（第 2 期）

(2020.8.17 ~ 2020.8.23)

DRM

1. 修複 dma-heap 導出 name 不準确的問題

dma-heap 為我們提供了一個輔助函數

heap_helper_export_dmabuf()

，用于将自定義的 heap 導出為 dma-buf。但實際運作時你會發現，通過該接口導出的 dma-buf name 并不是我們期望的 heap name，而是統一的 “heap-helpers” 字元串。這是因為該 helper 函數是在 heap-helpers.c 檔案中定義的，該函數在導出 dma-buf 時設定的 exp_name 預設為 KBUILD_MODNAME。如果 heap-helpers.c 隻參與到一個 kernel module 的編譯，那麼這個 KBUILD_MODNAME 宏定義的值就是 kernel module 的 name；但如果 heap-helper.c 參與到多個 kernel module 的編譯，這就存在一個問題：不同的 kernel module 它們的 KBUILD_MODNAME 定義不一樣，但它們都引用了 heap-helpers.o 檔案。而 heap-helpers.c 檔案隻會被編譯一次，即該檔案對 KBUILD_MODNAME 宏的預處理隻會有一次，那編譯器到底應該選哪個 kernel module 的 name 作為該檔案中 KBUILD_MODNAME 的值呢？答案是都不用，直接将 heap-helpers.c 的檔案名作為 KBUILD_MODNAME 宏定義的值（隻限于本檔案中），于是就出現了上面的問題。關于 KBUILD_MODNAME 多子產品的定義，可以參考：https://patchwork.kernel.org/patch/10060825/

為了解決該問題，Ezequiel Garcia（Collabora）新增了

dma_heap_get_name()

函數，用于擷取真正的 heap name。

詳情：[PATCH] dma-buf: heap-helpers: Set dma-buf exporter name

2. 為 dma-heap 添加 Device Heap

Ezequiel Garcia（Collabora）8月16日向 dma-heap 送出了一筆 patch，用于支援裝置強相關的 heap：Device Heap。Ezequiel 希望通過該 patch 抛磚引玉，和社群的開發者們一起探讨是否需要給 dma-heap 添加一個 system-agnostic （系統無關的）API，應用程式無需清楚自己所配置設定的 heap 具體是哪種類型，它唯一需要知道的是目前是在給哪個 device 配置設定 heap，至于最終所配置設定的 heap 是由 CMA 來管理，還是由 IOMMU 來管理，還是在 DMA pool 上，則由 Device Heap 驅動去決定，應用程式無需了解。該 patch 其實是參照着 drivers/media/common/videobuf2/videobuf2-dma-contig.c 來實作的，說白了就是一個基于 DMA-API 實作的 DMA-BUF exporter 驅動，非常簡單。

John Stultz（dma-heap maintainer，Linaro）針對該讨論給出了自己的觀點：他認為，dma-heap 設計之初就是給多裝置共享 heap 的。由于每個裝置可能有自己不同的硬體限制要求，隻有 APP 最清楚它的 buffer 将從哪個裝置傳遞給另外哪個裝置，是以 heap 的類型交給 APP 來指定是最為合适的。而 Ezequiel 的這筆 patch 則剛好與 dma-heap 的設計思想相反，它讓裝置驅動自己來決定 heap type，而上層 APP 根本不知道自己配置設定的 heap 到底屬于哪種 type，這種隻能适用于單個裝置的記憶體配置設定場景，在多個裝置之間共享并不是一個好的方案。對于 single-device allocation 的場景，與其在 dma-heap 裡增加接口，還不如在 DRM GEM 中增加接口來的更合理。

Ezequiel 會在本次的 LinuxPlumbers 2020 線上會議上開設專題來進一步讨論該話題。

詳情：[RFC] Experimental DMA-BUF Device Heaps

3. 為 dma-heap 引入自定義 CMA Heap

目前的 dma-heap 隻支援系統預設配置的 CMA 記憶體，不支援裝置自定義的 CMA 記憶體。為此，Kunihiko Hayashi（socionext）提了如下 Patch，新增

dma_heap_add_cma()

外部接口，用于将裝置驅動自定義的 CMA 記憶體導出給 dma-heap 。操作方法：裝置驅動首先調用

of_reserved_mem_device_init()

來初始化自己的 CMA reserved memory，然後調用

dma_heap_add_cma()

将自己的 CMA 作為 dma-heap 導出給應用程式使用。

John Stultz（dma-heap maintainer，Linaro）認可了該 patch，但是他希望該 patch 等到有實際裝置驅動使用該接口時再一起合入。

詳情：[PATCH] dma-buf: heaps: Introduce dma_heap_add_cma() for non-default CMA heap

4. 為 dma-heap 添加 Chunk Heap

對于大記憶體需求的裝置（如網卡），它們往往需要動态配置設定幾十到幾百兆的記憶體，這麼大的記憶體如果都按照一個 page 一個 page 的方式來配置設定的話，那麼就會大大增加系統開銷，降低系統性能。為此，有人提出了 “high-order page bulk allocation” 的概念（https://lore.kernel.org/linux-mm/[email protected]），即每次配置設定記憶體不再是以單個 page 為粒度，而是以多個 pages 為最小粒度進行配置設定，這個最小粒度為 2^n 個 pages，配置設定的接口為

alloc_pages_bulk

（目前還未合入主線）。正是基于這類需求，Hyesoo Yu（Samsung）向社群 dma-heap 送出了支援大記憶體的 heap allocator: Chunk Heap。

Chunk Heap 基于 CMA 來實作，同時借助于上面的

alloc_pages_bulk()

API，可以快速的配置設定 High-Order Pages。例如一個 64MB 的 dma-buf，可以由 1024 個 2^4 pages 來組成。該驅動在 dts 中的配置有兩點：（1）一個指向 CMA 預留記憶體的 phandle；（2）一個用來計算 page order 的 alignment 參數。

Brian Starkey（ARM）覺得該 patch 其實和 ARM 官方的 ION CPA（Compound Page Allocator，https://github.com/ARM-software/CPA） 有點類似，CPA 内部有一個工作線程和3個水位（high/low/fill），當 pool 達到 low 水位時，會自動觸發異步線程往 pool 裡填充 pages，直到 pool 達到 fill 水位為止。當 pool 達到 high 水位時（即之前所配置設定的 Pages 被釋放到 pool 中），後續所釋放的 page 将不再被歸還到 CPA pool 中，而是直接還給 system，以此來達到動态調節的目的，同時又不會對 System 記憶體造成太大的浪費。Brain 認為 chunk heap 可以借鑒一下 CPA 的實作。

John Stultz（dma-heap maintainer，Linaro）則對該 patch 持有保守态度。首先他認為該 chunk heap 需要借助 dts 才能完成驅動的注冊，這不符合現有 dma-heap 的注冊方式，他更推薦使用 Kunihiko Hayashi（socionext）送出的

dma_heap_add_cma()

接口。其次，因為該 patch 并沒有使用 cma 的标準接口，而是使用的

alloc_pages_bulk()

接口，他并沒有看出在性能上有多大提升。最後，他希望大家在送出 dma-heap patch 時，能夠多想想我們為什麼需要這個 patch？而不是這個 patch 是用來幹什麼的。

詳情：[PATCH 0/3] Chunk Heap Support on DMA-HEAP

AOSP

1. 新增 AidlMessageQueue 結構體

AidlMessageQueue

為

MessageQueue

的 AIDL 版本，借助該 struct，可以實作 MessageQueue 在程序之間傳遞。

詳情：aosp/interfaces[master]: Adding AidlMQDescriptor and GrantorDescriptor

2. systrace 新增 system property 跟蹤資訊

為了跟蹤 system property 的狀态變化，systrace 新增

TRACE_TAG_SYSPROP

标簽，可以跟蹤 system property 的 add/set/update 操作。

詳情：aosp/native[master]: Add systrace tag for system property

Vulkan

1. Vulkan-Docs 倉庫或将 master 分支更名為 main 分支

受全球政治正确影響，各大開源倉庫開始對部分敏感詞彙進行調整， 如 Linux、Mesa 都已決定将 master 分支更名為 main 分支，如今 Vulkan 工作組也開始讨論是否要将 Vulkan-Docs 倉庫的 master 分支修改成 main 分支。

詳情：Vulkan Working Group renaming default branch on Vulkan-Docs repository from ‘master’ to ‘main’

2. Vulkan 與 OpenGL 之間的互動實驗

Eleni Maria Stea （昵稱 hikiko）是一名就職于 Igalia（開源軟體咨詢公司，樹莓派4 的 vulkan 驅動就由該公司負責開發）Graphics Team 的工程師，他一直緻力于在 Mesa Iris Gallium3D 驅動中實作 OpenGL 與 Vulkan 的互動性開發。最近，他開始将自己工作中所總結的經驗分享到他的個人部落格中。關于 Vulkan 和 OpenGL 之間的互操作性文章總共有兩篇：第一篇介紹基本概念，第二篇示範代碼。

在第一篇中，hikiko 介紹了哪些場景（如 VR）需要實作 Vulkan 與 OpenGL 的互動，要實作這種互動需要哪些基本條件，以及實作的基本步驟。在第二篇中，以一個簡單的示例，搭配關鍵示範代碼，他詳細的介紹了如何實作一個由 Vulkan 建立的 image，被作為 OpenGL 紋理進行 GL 渲染，并最終由 shader 程式來檢驗結果的正确性。這兩篇文章寫的很不錯，非常值得參考！

詳情：[OpenGL and Vulkan Interoperability on Linux] Part 2: Using OpenGL to draw on Vulkan textures

3. Vallium: a software swrast vulkan layer FAQ

Dave Airlie，RedHat Graphics Team，Linux DRM maintainer，Mesa Vallium 作者，近日在他的個人部落格上發表了關于 Mesa Vallium 驅動的 FAQ。Mesa Vallium 驅動是一個基于 CPU 實作的 Vulkan 驅動，它本質上是一個将 Vulkan API 轉換成 Gallium3D LLVMpipe 實作的轉換層，嚴格意義上來說算不上是真正的 vulkan 驅動實作。

Dave 從如下幾方面回答了關于 Vallium 的常見問題：

• 什麼是 Vallium?
• 它是如何工作的？
• 它雖然慢，但是并不影響 Profiling
• 不要讓 Vallium 運作在真實的 Gallium3D 硬體驅動之上
• Vallium 在不具備 Vulkan 能力的硬體平台上将無法運作

詳情：Vallium: a software swrast vulkan layer FAQ

其它

1. Arm Mobile Studio

Arm Mobile Studio 是一套專用于優化、調試 Android 遊戲/App 的工具套件，它由如下 4 部分組成：

• Streamline：用于抓取 App 的性能資料，可以友善的檢視 CPU 和 GPU 的工作狀态；
• Graphics Analyzer：一幀一幀的跟蹤 Graphics Events，支援 OpenGLES 和 Vulkan API；
• Mali Offline Compiler：用于分析 Sharder 程式
• Performance Advisor：根據 Streamline 抓取的資料，自動生成詳細的性能指導意見。

詳情：Catch performance issues early with profiling and optimization insights for your entire team in Arm Mobile Studio Performance Advisor

2. ARM 釋出 ASTC 紋理壓縮工具 astcenc 2.0

Adaptive Scalable Texture Compression (ASTC)

是一種有損紋理壓縮格式，通過對紋理資料進行壓縮，以犧牲色彩品質為代價（通常人眼不易察覺），來換取性能的提升以及功耗的優化，這對于移動平台來說具有明顯的收益。該壓縮技術由 ARM 和 AMD 聯合開發，并最終授權給 Khronos 組織作為開放标準使用。

為了幫助開發人員友善的使用 ASTC 壓縮紋理，ARM 七年前開發了專門的紋理壓縮工具 astcenc，可以幫助開發人員對所需的紋理進行壓縮處理，不過該工具一直到今年年初都是采用的 ARM license 授權方式。而此次釋出的 astcenc2.0，則采用 Apache 2.0 開源許可，工具源碼也放在了 GitHub 上進行托管。astcenc 2.0 相較 1.0 在壓縮性能上得到了大幅提升，在支援 AVX2 指令集的 CPU 平台上，astcenc 2.0 的壓縮速度比 1.7 要快 3 倍，而圖像品質損耗則比 1.7 通常低 0.1 dB PSNR。此外，astcenc 2.0 還提供了 Core Codec Library，可以作為第三方庫直接內建到應用程式中，可以直接對 memory 中的紋理進行壓縮處理。

詳情：Create ASTC textures faster with the new astcenc 2.0 open source compression tool