Linux Graphics 周刊（第 8 期）

导读：

• dma-buf: Heaps: 代码重构及性能优化
• drm/uapi: 为 drm_mode_get_connector 添加详细说明
• drm/ttm: 一些小的修改
• AOSP/RenderEngine: 引入非线性 display color transform
• AOSP/SurfaceFlinger: 为 CaptureScreen buffer 添加 GRALLOC_USAGE_HW_COMPOSER usage
• Mesa 20.3.0 发布
• Khronos 发布 Vulkan 光线追踪（Ray Tracing）最终版
• Khronos: Vulkan 光线追踪最佳实践之混合渲染
• Collabora: 在 Wayland 中添加 Color Management 和 HDR 支持
• Dave Airlie：为什么和 Windows 共享 Linux Graphics 驱动代码并不是件好事

DRM

1. dma-buf: Heaps: 代码重构及性能优化

在经历了7轮 patch review 之后，John Stultz (dma-heap maintainer, Linaro) 的 dma-buf heap 重构 patch 终于可以合入主线了。此次 patch 对 dma-buf heap 做了较大改动，主要是删除了 heap-helpers.c 文件，将其原来的内容合并到 cma-heap.c 和 system-heap.c 中。并对 system heap 做了性能上的优化，例如对于 device 没有 touch 过的 buffer，CPU 访问该 buffer 就无需再做 cache 同步。以及优先采用大页内存分配来提高效率。值得一提的是，在前5轮的 patch 中曾还包含添加 system-uncached heap（还记得周刊第1期中曾报道的 system-uncached heap 吗？），用来在 system heap 上分配不带 cache 的 memory，这种 memory 对于需要频繁在 CPU 和 device 之间来回切换的场景能有明显的性能改善（因为不用频繁刷 cache 了）。但 DRM Maintainer Daniel Vetter 对此 patch 持有反对意见，他需要 John 给出相关数据来证明 system-uncached heap 在性能上确实有所收益，否则这样的 heap 在他看来没有多大意义（而事实上 John 在邮件中也很明确告诉 Daniel，在 userspace 这一侧，Android 的 Hikey960 gralloc 以及 codec2.0 的 patch 正焦急地等待着此 patch 的合入，因为它确实带来了性能的大幅提升）。为了能尽早将这部分 Patch 合入主线，John 只能暂时先放弃 system-uncached heap 的添加，先确保重构部分的修改合入主线再来慢慢跟 Daniel 周旋。该 patch 应该会在 linux-5.11 中和大家见面。

详情：[PATCH v7 0/5] dma-buf: Code rework and performance improvements for system heap

2. drm/uapi: 为 drm_mode_get_connector 添加详细说明

Simon Ser (Weston/wlroots/Sway Maintainer) 为 drm_mode_get_connector 结构体添加了详细的注释，包括如何执行一个 GETCONNECTOR ioctl 调用，如何强制发起一次 connector probe 操作，以及何时需要使用强制 probe 操作。

通常我们执行 GETCONNECTOR ioctl 需要执行2次，第一次用来获取 encoder & modes & property 的参数个数，用于在 userspace 为这些参数分配合适的内存空间。第二次调用则是真正的参数获取。需要注意的是，如果在两次 ioctl 中间出现了 connector hotplug，那么实际的参数个数就会发生变化，因此需要再重复调用该 ioctl 直到参数个数稳定下来。

如果我们在第一次调用时传入的 count_modes 指针为 null，则是表示当前我们要发起一次 force probe 操作，force probe 操作会重新更新当前的 connector 信息（包括 status、modes、EDID 等）。但 force probe 会比较耗时，它会完全阻塞当前的 ioctl，因此如果在屏幕画面更新的过程执行 force probe 则会出现 flicker 或 freeze 的现象。通常情况下 userspace 是不需要执行 force probe 操作的，因为 kernel 驱动在初始化时就已经帮我们做了这个事情，但某些特殊场景下还会用到，比如显示器菜单中的 “Scan connectors” 选项。

详情：[PATCH v3] drm: document drm_mode_get_connector

3. drm/ttm: 一些小的修改

Christian König (AMD 工程师) 对 ttm driver 做了如下修改：

1. 移除 vendor driver 中多余的 #include ttm_module.h 代码
2. 删除 sysfs 下的 ttm 目录，取而代之的是 debugfs 下的 page_pool 调试节点
3. 只针对 use_dma_alloc 的 pool 才做初始化

详情：[PATCH 1/4] drm/ttm/drivers: remove unecessary ttm_module.h include

AOSP

1. RenderEngine: 引入非线性 display color transform

A display color transform is a non-linear color matrix that should be applied in gamma space. Previously the non-linear display color transform is mixed into the linear color matrix that results in incorrect color inversion behaviour.

详情：aosp/native[master]: RenderEngine: Introduce non-linear display color transform

2. SurfaceFlinger: 为 CaptureScreen buffer 添加 GRALLOC_USAGE_HW_COMPOSER usage

通常截屏时会有个动画的过程，即截屏的一瞬间屏幕截图会缩放一定大小，使得屏幕截图看起来像是悬浮在当前 UI 界面上，此时屏幕截图所在的图层就需要和其它 UI 图层一起做 compose。对于有些平台来说，他们的 DPU 硬件不具有 IOMMU 功能，因此只能处理物理连续的 buffer，对于非连续 buffer 则无法处理。为了能让截图也能在这些平台上使用 DPU 做合成，它们只能通过 GRALLOC_USAGE_HW_COMPOSER 这个 usage 来告诉 gralloc 当前需要分配一个物理连续的 buffer，以便后续使用 DPU 做合成。下面的 patch 就是用来做这件事的：

详情：aosp/native[master]: SurfaceFlinger: captureScreen buffer set GRALLOC_USAGE_HW_COMPOSER usage

Mesa

Mesa 20.3.0 发布

此次发布的重要 feature 如下:

• lavapipe for vulkan swrast
• v3dv vulkan driver for raspberry PI devices
• lots of clover work, in particular spir-v for clover
• tons of stuff I’ve not mentioned

详情：[Mesa-dev] [ANNOUNCE] mesa 20.3.0-rc1

Vulkan

1. Khronos 发布 Vulkan 光线追踪（Ray Tracing）最终版

11月23日，Khronos® 发布了 Vulkan®、GLSL 和 SPIR-V 扩展的最终版本，这些 spec 将光线追踪无缝地集成到了现有的 Vulkan 框架中。这是一个非常重要的里程碑，因为它是业界首个开放的、跨厂商的、跨平台的光线追踪加速标准，可以使用现有的 GPU 计算或专用的光线追踪 IP 来进行部署。Vulkan 光线追踪对于那些使用过 DirectX Raytracing（DXR）的人来说都是很熟悉的，同时它也引入了一些高级功能，例如通过光线追踪可以与 Host CPU 之间实现负载均衡的能力。虽然光线追踪将首先应用于桌面系统，但这些 Vulkan 扩展的设计目的也是在鼓励大家将其应用于移动平台。

这些扩展最初于2020年3月作为临时版本发布的（详见周刊 XDC2020 中 “Ray-tracing in Vulkan” 小节），从那时起 khronos 工作小组就收到了来自硬件厂商和软件开发人员的积极反馈。而此次发布的 Vulkan 光线追踪扩展规范仅仅只是个开始，在接下来的几天甚至几周内，其他生态系统组件（如 Shader 工具链和 Validation Layers 验证层）将同步更新，以支持光线追踪功能，确保开发人员可以在其应用程序中轻松使用这些扩展。这些生态系统更新的进展可以在 GitHub 上进行查询。同时，支持 Vulkan 光线追踪的 Vulkan SDK（1.2.162 或更高版本）将在12月中旬发布！

此次最终版本新增了如下扩展：

Vulkan extension specifications

• VK_KHR_acceleration_structure
• VK_KHR_ray_tracing_pipeline
• VK_KHR_ray_query
• VK_KHR_pipeline_library
• VK_KHR_deferred_host_operations

SPIR-V extensions specifications

• SPV_KHR_ray_tracing
• SPV_KHR_ray_query

GLSL extensions specifications

• GLSL_EXT_ray_tracing
• GLSL_EXT_ray_query
• GLSL_EXT_ray_flags_primitive_culling

这篇文章将着重介绍 Vulkan 光线追踪扩展的临时版本和最终版本之间主要区别，以及阐述这些修改背后的原因是什么。

详情：Vulkan Ray Tracing Final Specification Release

2. Khronos: Vulkan 光线追踪最佳实践之混合渲染

本文是对上面文章的补充，本篇将着重描述如何让 Vulkan 光线追踪和普通的光栅化操作一起混合使用，以实现实时光线追踪反射的效果，这是一种将在这篇文章中深入研究的技术，同时也将讨论 Vulkan 实时光线追踪的常用方法。本文适用于熟悉 Vulkan API 的开发人员阅读，并以 Wolfenstein:Youngblood 游戏作为案例进行讲解。

详情：Vulkan Ray Tracing Best Practices for Hybrid Rendering

Wayland

Collabora: 在 Wayland 中添加 Color Management 和 HDR 支持

Pekka Paalanen（Wayland/Mesa Maintainer）于11月19日在 Collabora 官网发表了一篇关于 Wayland 中 color management 和 High Dynamic Range 的文章，摘要如下：

目前 Wayland 对颜色管理（Color Management）的支持仍然比较薄弱，同时还缺乏对宽色域（HDR）图像的支持，而这些功能在电影和广播行业已经流行多年了（例如Netflix HDR UI）。
虽然 X11 上对颜色管理已经有了相对成熟的 tuning 工具及操作流程，但就连 X11 也没有实现对 HDR 的支持。目前在 Linux 图形系统中，在 HDR 显示器上观看 HDR 内容的唯一方法就是直接使用 DRM-KMS-API，换句话说就是不使用任何窗口系统，即不使用任何桌面环境。Kodi 是极少数能够做到这一点的应用程序，而本文则会针对以上问题，来讨论如何在 Wayland 上来解决这些问题。

同时他还向 wayland 协议提交了一份关于 Color Management 的详细文档（草稿），用于在 wayland 协议中添加对颜色管理和 HDR 的支持。虽然这个 patch 可能需要经历 1～2 年的时间才能被最终合入，但是这开启了 wayland 对厂商 PQ 功能支持的大门，我们期待这一 feature 能早日合入 wayland 主线！

详情：Developing Wayland Color Management and High Dynamic Range

其它

1. Dave Airlie：为什么和 Windows 共享 Linux Graphics 驱动代码并不是件好事

最近因为 Phoronix 上的一篇关于在 Windows 和 Linux 之间共享代码文章《Intel’s Graphics Driver Now Sharing ~60% Codebase Between Windows/Linux, 90~100% The Performance》，在评论区引来了热议，对此 DRM release Maintainer Dave Airlie (RedHat, Graphics Team) 在自己的博客中发表了他的个人看法。以下是部分摘要：

作为一个共享的 Windows/Linux stack，Vendor 厂商考虑更多的是他们自己的利益，而非 Linux 社区的利益。为什么这不是个好点子？我首先要说的是，这并不总是一个坏主意。从理论上讲，使用开放源码开发模型的优点来生产这样一个 stack 是可行的，但是大多数厂商似乎都失败了。他们将开源视为一种发布模式，他们在内部进行开发，并在一堆代码迭代之后每隔几周就将结果提交到 github 仓库中。他们构建包含这些开放源码的产品，但是却从不花时间去构建项目或围绕它们的社区进行互动。

如果我必须共享 Windows/Linux 驱动程序栈，我将(带有偏见的)从最开放的项目开始，并将其带到一个封闭的项目中。我绝对不会以一个新的内部项目开始，试图破坏这两者。例如，如果我需要创建一个Windows OpenGL 驱动，我可以:

a) 编写一个完整的 GL 实现，并每隔几周就把它抛到一边。让 Windows/Linux 用户使用它，Linux 用户失去了共享栈，发行版失去了一个依赖，而不必建立一个 multi-vendor 的依赖栈，Windows 真的没有任何收获，但我却掌握了自己的命运(社区则不受任何影响)。

b) 使用 Mesa 并 upstream 我的驱动，这样就可以和 Linux 栈共享我的驱动，将 Windows 代码添加到 Mesa stack 中，这样就可以和 Windows 共享我的驱动。我与其他厂商分享了外部开发的好处，Windows 从中受益，Linux 则保留了它的生态优点。

对于那些希望在操作系统之间共享更多厂商代码的人来说，这是一个警告，它通常不会以 Linux 变得更好而告终，而是会以 Linux 变得更加碎片化、难以维护以及难以持续发展而告终。

详情：Linux graphics, why sharing code with Windows isn’t always a win

2. Simon Ser: 10 月月报

来自 Wayland release Maintainer Simon Ser 的月报，感兴趣的可以读一下。

详情：Status update, November 2020