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 类似。
更多详细内容，请查看如下提交：
- wsi/x11: Hook up VK_PRESENT_MODE_FIFO_RELAXED_KHR
- Implement GLX_EXT_swap_control and GLX_EXT_swap_control_tear
- [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 白皮书》
信息来源：
- Intel Lands Adaptive-Sync/VRR Into Modesetting X.Org Driver
- modesetting: Lay the foundation for enabling VRR
- 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