Linux Graphics 周刊（第 5 期）

導讀：

• Android11 正式釋出
• drm/dev: 對 drm_dev_init() 說再見
• drm/gem: 删除 drm_gem_vram_kmap() 接口
• binder: 新增 BINDER_FREEZE ioctl
• fastboot: 新增 modules 分區
• Mesa-dev：GLX/WSI 合入新 feature，改善顯示卡頓問題
• RADV: 新增 override_vram_size debug 選項
• Zink: 性能大幅提升
• Vulkan-Doc: Vulkan 1.2.153 釋出，master 分支已切換到 main 分支
• xf86-video-modesetting：正式合入對 Adaptive-Sync/VRR 的支援
• Hikari Wayland Compositor 2.2.0 釋出

DRM

1. drm_prime_pages_to_sg() bugfix

每個 dma 裝置都有自己的尋址能力限制，如果配置設定出來的記憶體超過了 dma 硬體的尋址能力，那就會出現異常。目前的 drm_prime_pages_to_sg() 中就存在這樣的漏洞，配置設定 sg_table 時沒檢查目前 dma 硬體的尋址能力範圍，因而可能導緻配置設定出的記憶體空間超出 dma 的尋址能力。該問題已經在 virtio-gpu 複現，因而 Gerd Hoffmann (RedHat) 提了如下 patch 來修複該 bug。

詳情：[PATCH v4 1/1] drm: allow limiting the scatter list size

2. atomic-helper: calc_timestamping_constants() 函數調整

Ville Syrjala 提了個 patch，将 drm_atomic_helper_calc_timestamping_constants() 函數徹底從 drm_atomic_helper_update_legacy_modeset_state() 中解救出來，實作了 timestamps 和 legacy modeset 之間的解耦。

詳情：[PATCH 1/3] drm/atomic-helper: Extract drm_atomic_helper_calc_timestamping_constants()

3. drm/dev: 對 drm_dev_init() 說再見

Daniel Vetter（drm-misc maintianer, Intel）送出的如下 patch merge 之後，我們在 DRM 裝置驅動中将再也沒有機會使用 drm_dev_init() 來做初始化了，取而代之的是 devm_drm_dev_alloc()。使用該函數将帶來極大的友善，我們不再需要做更多的容錯處理，也不需要在初始化失敗時調用 drm_dev_put()，devm_* 接口本身就能幫我們處理好資源釋放的問題。

詳情：[PATCH 09/24] drm/dev: Remove drm_dev_init

4. drm/gem: 删除 drm_gem_vram_kmap() 接口

對于 GEM VRAM 接口而言，drm_gem_vram_vmap() 和 drm_gem_vram_kmap() 的功能重複了，他們都用于将 gem object 映射到 kernel space 的位址空間，而 drm_gem_vram_vmap() 相比 drm_gem_vram_kmap() 調用參數更簡潔，且使用率更高。是以 Thomas Zimmermann (SUSE) 索性直接删除了 vram 中的 drm_gem_vram_kmap() 和 drm_gem_vram_kunmap() 函數。

詳情：[PATCH] drm/vboxvideo: Use drm_gem_vram_vmap() interfaces

AOSP

1. Android11 正式釋出

上周三 Google Android11 正式釋出，釋出當天 Google 便将 AndroidR 的代碼同步推送到 AOSP 主分支上，開發者們可以立即下載下傳體驗該代碼所帶來的新功能。AndroidR 主要聚焦在三個方面：以人為本、靈活控制和隐私安全。下面我們就通過代碼一起來了解一下，AndroidR 在 Graphic 子產品上都新增了哪些 feature（一般晶片廠商和手機廠商在半年前就已經拿到了這部分的代碼）：

Gralloc 4.0

IMapper 新增接口:

• get()
• set()
• getFromBufferDescriptorInfo()
• getReservedRegion()

借助于 IMapper 的 get() 和 set() 接口，我們可以擷取/設定任何資料類型的參數，這大大增強了 Gralloc 底層實作的靈活性與可擴充性。通過對 get() 接口的封裝，GraphicBufferMapper 可以實作諸如 getWidth()、getHeight()、getPixelFormatFourCC()、getBufferId() 等諸多常用 buffer 屬性操作接口，統一了 gralloc 的操作接口。

IAllocator 則沒有新的變化。

Composer 2.4

Callbacks 新增:

• HWC2_PFN_VSYNC_2_4
• HWC2_PFN_VSYNC_PERIOD_TIMING_CHANGED
• HWC2_PFN_SEAMLESS_POSSIBLE

Device Functions 新增接口:

• HWC2_PFN_GET_DISPLAY_CONNECTION_TYPE
• HWC2_PFN_GET_DISPLAY_VSYNC_PERIOD
• HWC2_PFN_SET_ACTIVE_CONFIG_WITH_CONSTRAINTS
• HWC2_PFN_SET_AUTO_LOW_LATENCY_MODE
• HWC2_PFN_GET_SUPPORTED_CONTENT_TYPES
• HWC2_PFN_SET_CONTENT_TYPE
• HWC2_PFN_GET_CLIENT_TARGET_PROPERTY
• HWC2_PFN_SET_LAYER_GENERIC_METADATA
• HWC2_PFN_GET_LAYER_GENERIC_METADATA_KEY

通過以上新增接口的名字，我們大緻可以看出這些接口都是為了支援 VRR (Variable Refresh Rate，可變重新整理率)以及高幀率顯示裝置而開放的接口。

HWC 2.4 接口定義：

platform/hardware/libhardware

gralloc4.0 & composer-2.4 相應的 HIDL 接口定義：

platform/hardware/interfaces

Native Framework

• 删除了 libagl

  libagl 是 Android 早期使用 CPU 實作的一套純軟體 OpenGL 函數庫，由于沒有硬體加速功能，因而運作效率極低，在 AndroidR 中該目錄已被徹底移除。

• 新增 libnativedisplay.so

  為 Choreographer 添加 native 層，并将 libhwui 下的 surface texture 移到 nativedisplay 目錄下，統一生成 libnativedisplay.so。

• 删除了 bufferhub
• surfaceflinger 新增大量修改

具體請參考：

platform/frameworks/native

2. binder: 新增 BINDER_FREEZE ioctl

上周 libbinder 合入了一筆 patch，在 IPCThreadState 類中新增 freeze() 方法，用于适配底層 kernel 新增的 BINDER_FREEZE ioctl。該 ioctl 主要用于當機某個指定的 binder 程序，一旦程序被 freeze，所有向該程序發起的 binder transaction 都會直接傳回一個錯誤碼。當機時會指定一個逾時參數，當逾時時間到後被當機的程序就會自動解凍，然後就可以繼續處理新的 binder 請求。當然調用者也可以立即解凍某個已被當機的 binder 程序，通過 enable 參數來區分。至于該 ioctl 的使用場景及作用，目前本人還不太清楚。

詳情：aosp/native[master]: binder: adopt BINDER_FREEZE api

3. fastboot: 新增 modules 分區

fastboot 分區清單中新增了個 modules 分區，對應的 image 檔案為 modules.img，分區挂載路徑為 /modules，目前還不太清楚該分區具體用來存放哪些子產品（kernel modules？是否和 GKI 有關？），但分區類型被标記為 ImageType::Normal，而不是 ImageType::BootCritical，說明并不是一個必須的分區，具體的作用還有待進一步确認。

詳情：aosp/core[master]: fastboot: add mainline partition

Mesa

1. Mesa-dev：GLX/WSI 合入新 feature，改善顯示卡頓問題

上周四，RedHat 工程師 Adam Jackson 向 mesa-20.3 開發分支合入了6筆 patch，為 GLX/WSI 新增 GLX_EXT_swap_control、GLX_EXT_swap_control_tear 和 VK_PRESENT_MODE_FIFO_RELAXED_KHR 接口，用于改善顯示抖動的問題。

• GLX_EXT_swap_control：用于實作 glXSwapIntervalEXT() 函數，用來設定 swap buffer 的間隔時間，間隔時間以 vsync 周期為機關，主要用于渲染和顯示同步。例如 glXSwapIntervalEXT(2) 代表 glutSwapBuffers() 需要等待2個 vsync 後才傳回。
• GLX_EXT_swap_control_tear：和 GLX_EXT_swap_control 類似，但唯一不同是 glXSwapIntervalEXT() 設定的時間間隔可以是負數，用來表示如果目前發起的 swap 操作已經滞後了一個 vsync，那麼就不要等待原來設定的時間間隔了，直接将 buffer swap 出去。這樣的操作可以大大改善遊戲的卡頓問題，但副作用也很明顯，就像它的名字一樣，會帶來撕裂的問題。
• VK_PRESENT_MODE_FIFO_RELAXED_KHR：是 GLX_EXT_swap_control_tear 的 vulkan 版本，功能和 GLX_EXT_swap_control_tear 類似。

更多詳細内容，請檢視如下送出：

1. wsi/x11: Hook up VK_PRESENT_MODE_FIFO_RELAXED_KHR
2. Implement GLX_EXT_swap_control and GLX_EXT_swap_control_tear
3. [Mesa-dev] Heads up: new GLX/WSI presentation features in git

2. RADV: 新增 override_vram_size debug 選項

在 mesa-20.3 開發分支中，Bas Nieuwenhuizen 在 DriConfig 中新增了 override_vram_size debug 選項，用于削減應用程式可見的 VRAM 顯存大小，主要用于調試目的，目前僅 RADV 驅動中支援該功能。

詳情：radv,gallium: Add driconf VRAM override

3. Zink: 性能大幅提升

Zink 是 mesa 中基于 Vulkan API 實作的 OpenGL 驅動，本質上是一個 API 轉換層，可以運作在任意真實的 Vulkan 硬體驅動之上。建立 Zink 的主要目的是為了友善那些還沒有能力遷移到 Vulkan API 的應用程式或遊戲廠商，幫助他們暫時從 OpenGL 過渡到 Vulkan，同時也有助于 Vulkan 生态的建立。

Mike Blumenkrantz，一直緻力于 Zink 的開發工作，近期在他的部落格中宣布 Zink 的性能有了重大突破，甚至在某些場景下還優于本地真實 OpenGL 驅動的性能！他做了一個小規模的 benchmark 測試，取相同的 Mesa 節點，讓 Zink 運作在 Intel “ANV” Vulkan 驅動之上，與同節點的 Intel “Iris” Gallium3D OpenGL 硬體驅動進行對比測試，結果卻驚人的發現在某些 case 中 Zink 的性能大大超過了 Iris，這是非常令人振奮的消息！要知道，去年 Zink 的性能簡直不堪入目。該測試總共 2500 項，而 Zink 通過率已達到了 91%，這已經是相當不容易的了。當然，在其它某些 case 中，Zink 的性能仍然落後于本地 OpenGL 驅動。

詳情：Zink OpenGL-Over-Vulkan Driver - Performance Is Turning Out Better Than Expected

Vulkan

Vulkan-Doc: Vulkan 1.2.153 釋出，master 分支已切換到 main 分支

上周一 Vulkan 1.2.153 釋出，沒有新增 Extension，主要完善了 VK_EXT_memory_budget、VK_KHR_buffer_device_address 等接口的開發文檔。不過從該版本開始，Vulkan-Doc 倉庫的 master 分支正式切換到 main 分支，後續所有的修改都在 main 分支上進行，而 master 分支則被當機，不再接受新的送出。

詳情：Vulkan 1.2.153 Released

Xorg

xf86-video-modesetting：正式合入對 Adaptive-Sync/VRR 的支援

名詞解釋：

• VRR：Variable Refresh Rate，可變幀率，即 Display 硬體的 Vsync 周期是動态可變的，一般普遍認為可變幀率的範圍是 9~240Hz。
• Adaptive Sync: VESA DisplayPort 1.2a 引入的一個行業标準，用于定義 DisplayPort 與具有 VRR 能力的顯示器之間的傳輸協定。通過 Adaptive Sync 技術，GPU 在渲染完一幀圖像後，Display 就可以馬上進行顯示，而無需等到固定的 Vsync 邊沿到來時才觸發顯示。
• FreeSync：AMD 廠商基于 Adaptive Sync 技術實作的一套軟體/硬體整體解決方案，它是一套開放式的标準，免授權費，是以面闆廠商可以直接使用該技術而無需支付額外的授權費。FreeSync 不僅支援 DisplayPort 接口，還支援 HDMI 接口。另外，支援 FreeSync 的顯示器必須搭配 AMD GPU 才能使用 VRR 功能。
• G-Sync: NVIDIA 廠商實作的一套類似 Adaptive Sync 的技術，它是一套完全封閉的軟硬體整體解決方案，從面闆制作到認證出貨，全程由 NVIDIA 跟蹤指導，且需要向面闆廠商收取高昂的授權費。同樣的，支援 G-Sync 的顯示器必須搭載 NVIDIA 的 GPU 才能正常使用 VRR 功能。

之前曾在我的星球中報道過關于 Intel 添加 VRR 支援的消息：《Intel i915 DRM 驅動将添加對 VRR 的支援》、《Xorg 将添加 Adaptive-Sync/VRR 的支援》，而就在上周二，xorg-server 終于合入了對 Adaptive-Sync/VRR 的支援。

Adaptive-Sync/VRR 最早由 AMD 的 xf86-video-amdgpu 驅動支援，而此次合入的 VRR patch 其實就是從 amdgpu 那 porting 過來的。不同于 AMD，Intel 開源 X 驅動 xf86-video-intel 早已被廢棄，多年來 Intel 的開源 X 驅動都是直接送出到公共的 xf86-video-modesetting 驅動中的。也就是說，此 VRR patch 合入之後，不但可以支援 Intel 顯示卡的 VRR 功能，還可以支援 AMD 顯示卡的 Adaptive-Sync/FreeSync 功能。

不過需要注意的是，并不是在你的電腦上安裝了 xf86-video-modesetting 驅動就一定支援 VRR 功能，VRR 的支援需要整個系統都支援才可以正常使用，這涉及到 DRM kernel 驅動、Xorg Server、Mesa 3D 驅動的完整支援，任何一個子產品的不相容都将導緻無法正常使用 VRR 功能。更令人沮喪的是，目前合入 VRR 的 patch 是在 xorg-server 1.21 版本中，此版本已經開發了兩年半時間，至今仍然沒有 release 正式版本出來，這可能和目前 xorg 社群都把主要精力放在 Wayland 開發上有關。換句話說，在 xorg 正式 release 1.21 版本之前，我們仍然無法享用該 patch 所帶來的 VRR 功能。

關于 Adaptive-Sync/VRR 的詳細介紹，可以參考本人翻譯的《VESA Adaptive-Sync / AMD FreeSync / VRR 白皮書》

資訊來源：

1. Intel Lands Adaptive-Sync/VRR Into Modesetting X.Org Driver
2. modesetting: Lay the foundation for enabling VRR
3. modesetting: Allow users to opt-in VRR support

Wayland

Hikari 2.2.0 釋出

Hikari 是一款支援 X11 和 Wayland 協定的 Window Manager / Compositor，類似于 GNOME 桌面，不同于其它桌面系統，Hikari 主要運作在 FreeBSD 系統上。當然，它的 Wayland Compositor 也可以運作在 Linux 系統上。它的 Wayland 基于 wlroots 庫實作，使用 darcs 進行版本控制。

上周二 Hikari 社群釋出了 2.2.0 版本，該版本的一個重大更新是添加了對 WayVNC 的支援，可以作為 Wayland VNC server 進行遠端連接配接通路圖形桌面。

詳情：hikari 2.2.0 is out