Linux Graphics 周刊（第 9 期）

很抱歉！Linux Graphics 周刊可能要烂尾了！正所谓鱼和熊掌不可兼得，写周刊的时间也占据了我个人学习精进的时间，后期将还是回归到以 DRM 博客为主的文章发表。如果你对 Linux Graphics 周刊感兴趣，可以给我私信或留言，共同参与到 Linux Graphics 周刊的撰写中来，为我分担一份力，也帮助自己拓展技术视野。

导读

• dma-buf: 添加 sysfs 统计节点
• fbdev: UDLFB 驱动将被移除
• drm/vkms: Add setup and testing information
• Zink: 添加 Tessellation Shader 的支持
• 微软向 Mesa 添加 SPIR-V to DXIL 的转换库，用于支持 WebGPU
• Mesa-21 将开始支持 Direct3D-12 ，仅限于 WSL 环境
• Lavapipe：新增 VK_EXT_transform_feedback 扩展支持
• Mesa 21.0 删除了 Classic OSMesa
• 树莓派：V3DV Vulkan 驱动已支持 Wayland 窗口系统
• 树莓派：Mesa 21.0 优化 OpenGL 驱动的 Blit 操作
• XWayland 21.1 将从 X.Org Server 中剥离出来
• Wayland 1.19 即将发布
• Weston 新增 YUV 测试 demo
• Collabora: A Wayland driver for Wine
• Khronos：Vulkan SDK、Tools 和 Drivers 已添加对光线追踪的支持
• RenderDoc 1.11 发布
• KDE: Plasma KWin 如何在不同刷新率的屏上工作, 以及如何在多线程上进行合成任务

DRM

1. dma-buf: 添加 sysfs 统计节点

新增如下 sysfs 统计信息：

/sys/kernel/dmabuf//exporter_name
/sys/kernel/dmabuf//size
/sys/kernel/dmabuf//dev_map_info

以上节点信息需要开启 CONFIG_DMABUF_SYSFS_STATS 选项才能看到。

详情：[PATCH] dmabuf: Add the capability to expose DMA-BUF stats in sysfs

2. fbdev: UDLFB 驱动将被移除

多年来，一直有人呼吁废除 Linux 的 fbdev 驱动，转而使用更高级的 DRM 驱动替代。虽然硬件厂商现在倾向于使用 DRM 驱动程序（以及 fbdev emulator），但在嵌入式领域直接切换到 DRM 尚且还不太成熟。但是至少有一个 fbdev 驱动现在看起来可以被移除了，转而使用它的 DRM 版本。来自 SUSE Graphics Team 的Thomas Zimmermann 提议将 UDLFB 驱动从内核主线中移除，因为它已经事实上被 DRM UDL 驱动程序所代替了。UDL 为 Usb DisplayLink 的缩写，它们专是用于支持基于 DisplayLink USB 2.0 显示适配器的驱动程序。在过去的几年中，UDL DRM 驱动程序一直是人们关注的焦点，而 UDLFB 驱动却没有受到太多关注，因此 Thomas 决定移除该 fbdev 驱动。

详情：Another Linux FBDEV Drover Poised For Removal In Favor Of Superior DRM Alternative

3. drm/fb-helper: 各种 fixes 和 cleanups

详情：[PATCH v2 00/10] drm/fb-helper: Various fixes and cleanups

4. drm/vkms: Add setup and testing information

Sumera Priyadarsini 为 VKMS 内核文档新增了使用说明，包括如何配置 VKMS 驱动，以及如何使用 IGT 测试工具对 VKMS 进行测试操作，适合刚接触 VKMS 的初学人员。

详情：[PATCH V2] drm/vkms: Add setup and testing information

Mesa

1. Zink: 添加 Tessellation Shader 的支持

Zink 是基于 Vulkan 实现的 OpenGL Gallium3D 驱动，为那些还没有能力从 OpenGL 迁移到 Vulkan 的厂商提供了过渡方案。在 Mesa 21.0 中，Zink 引入了对 ARB_tessellation_shader 扩展的支持。Tessellation Shader（曲面细分着色器）是 OpenGL 4.0 的一个关键 Extension，也是 Zink 除了 ARB_gpu_shader5 和 ARB_texture_gather 扩展外，在 Mesa 主线上实现 GL 4.0 的又一个扩展。

详情：Zink OpenGL-On-Vulkan Lands Tessellation Shader Support In Mesa 21.0

2. 微软向 Mesa 添加 SPIR-V to DXIL 的转换库，用于支持 WebGPU

前不久，微软向 Mesa-21.0 提交了一个新的转换库 ———— spirv_to_dxil，该库用于将 spirv 转换为微软的 DXIL。这个转换的目的其实是为了实现 Direct3D 对 WebGPU 网页应用程序的支持。

WebGPU 是目前正处于开发阶段的 W3C 标准，它作为 WebGL 的继承者，由微软和其他公司共同参与开发。WebGPU 是基于现代 Graphics/Compute 理念设计的，它的 Shader 语言是 WGSL，是一种非常类似于 spirv 的中间表达产物。正因如此，微软正在尝试利用 Mesa 将 WGSL 转换为 spirv，并最终转换成 DXIL 以供 Windows Direct3D 驱动使用，这样微软就不必自己完全实现从 WGSL 到 DXIL 的转换过程了。所以这看起来像是 Mesa 在 Windows 上的一种新的用途，即在 Direct3D 驱动的 web 浏览器上支持 WebGPU 的 WGSL。但是目前这个 “spirv_to_dxil” 库的功能还非常薄弱，据说只能编译一个 fragment shader 程序。

详情：Microsoft Adds SPIR-V To DXIL Library In Mesa - With A Focus On WebGPU Support

3. Mesa-21 将开始支持 Direct3D-12 ，仅限于 WSL 环境

mesa 21.0 的一大改进是支持 Windows WSL2 构建微软 Direct3D-12 Gallium3D 驱动代码。前段时间，Direct3D 12 Gallium3D 代码的初始版本被合并到 Mesa 中，以便在 Windows 环境下使用。而这次的合并的内容则是如何在 Windows Linux 子系统（WSL）上对该早期代码的运行支持。它包括在 Linux 上构建 Direct3D 代码的能力，虽然在 WSL 之外并没有什么卵用。

WSL 方面的这项工作最终是为了让 OpenGL（包括 OpenCL）在 Windows Subsystem for Linux 下工作，并反过来在主机上的 Windows D3D12 驱动上运行，类似于 Windows for OpenGL 下当前的 Mesa 支持，或 Windows 本地的 OpenCL TOP D3D12 驱动程序。因此这项工作并不是要在 Linux 本地支持 Direct3D 以此来帮助 Linux 游戏的移植的。总的来说，这仍然是一个仍未完成的工作，可能要几个月后才能看到一个良好的开箱即用的体验，特别是在 WSL 发行版中需要更多的时间。

详情：Mesa 21.0 Merges Initial Direct3D 12 Support For WSL

4. Lavapipe：新增 VK_EXT_transform_feedback 扩展支持

Lavapipe 首次出现在 Mesa 20.3 中，它是基于 CPU 实现的 Vulkan 驱动。Lavapipe 的工作仍然由 Red Hat 的 David Airlie 主导，他在开源图形驱动领域可是相当多产的。Lavapipe 在 Mesa 21.0 中的最新特性是对 Vulkan VK_EXT_transform_feedback 扩展的支持。类似的，LLVMpipe 也在一定程度上提供了这种 transform feedback 功能。

VK_EXT_transform_feedback 扩展是在两年前引入的，用于协助 DXVK / VKD3D 和其他图形 API 的移植工作。
除此之外，这次的 Lavapipe 也添加了一些其他的 Vulkan 扩展，如 KHR_descriptor_update_template、KHR_push_descriptor、EXT_shader_stencil_export 等等。Mesa 21.0 的 feature 要到2月初才会 freezee，所以还是有充足的时间来实现 Lavapipe 的其它功能的。

详情：Lavapipe Continues Advancing CPU-Based Vulkan - Now Supports Transform Feedback

5. Mesa 21.0 删除了 Classic OSMesa

在进行 Mesa core 的一些清理工作时，Eric Anholt 在下一季度即将发布的 mesa 21.0 中删除了经典的 OSMesa（Off-Screen-Mesa，离屏渲染） 支持。那些希望在 2020 年及以后使用 Mesa soft-rendering 的用户应该尽量使用 LLVMpipe，否则 Softpipe 应该无法用于你的软硬件平台。LLVMpipe 提供了更好的性能，更不用说 OpenGL 4.6 了，而且是一直都在维护中的。由于经典的 OSMesa 代码已渐渐老去，且近年来很少用于离屏渲染，因此经典的 OSMesa 代码已经被删除了。

Eric Anholt 在 pull request 中这样描述道：“我一直在 Mesa core 中处理格式方面的工作，我真的为经典的 OSMesa 的存在而烦恼。src/mesa/swrast 代码很烂，我们不鼓励开发人员使用它。同时，由于 OSMesa 测试不足，我们已经发现 在 Gallium 版本中有许多 Bug。因此我们推荐开发人员改用 softpipe/llvmpipe（如果他们坚持使用 OSMesa 的话），我们应该修复已知的 Bug 并删除老的代码。”

关于 OSMesaGetDepthBuffer 的已知错误、内存泄漏以及 Windows 的 GL 符号表问题都已经得到了解决，因此 Anholt 删除了经典的 OSMesa。正如 Anholt 在提交报告中指出的那样，最终对使用者的影响应该会很小，“在我对 OSMesa 使用者的调查中，Debian 是使用 OSMesa 以及一些非 LLVM 架构（sh4、alpha等）的坚持者，到了今天，他们已经切换到基于 softpipe 的 gallium OSMesa。为了防止人们运行错误的 OSMesa（在某种程度上，运行 OSMesa 是正确的），请直接删除经典版本。”

详情：Classic OSMesa Retires In Mesa 21.0 As The Worst Of The Software Rendering Paths

6. 树莓派：V3DV Vulkan 驱动已支持 Wayland 窗口系统

今年，Raspberry Pi 的 V3DV Vulkan 驱动发展的势头相当迅猛，V3DV 驱动就在两个月前已经合入到了 Mesa 20.3 中，且已经通过了 Vulkan 1.0 CTS 测试。而最近，V3DV 又添加了对本地 Wayland 的支持！一位独立开源贡献者为 V3DV 设计了 Wayland WSI (窗口系统集成)支持，并通过一系列步骤将其合并到了主流 Mesa 中，也就是下个季度即将发布的 Mesa 21.0。现在树莓派4的 Broadcom VideoCore GPU 可以与 Wayland 窗口系统无缝集成了。

详情：Raspberry Pi’s V3DV Vulkan Driver Now Supports Wayland

7. 树莓派：Mesa 21.0 优化 OpenGL 驱动的 Blit 操作

随着 V3DV 初始里程碑的实现，更多性能相关的工作正如火如荼的进行着。同时，V3D OpenGL 驱动程序也在不断的改进。在 Mesa 21.0 中，V3D OpenGL 驱动实现了一种基于 tile （图块）渲染的高效方法，该方法利用了 tile buffer 硬件。同时，在某些情况下 tile buffer 硬件还可以处理多采样解析。总而言之，合入 Mesa 21.0 的新代码应该在 blitting 操作中提供一些细微但可测量的速度优势。同时，基于 VC4 驱动程序支持的旧的 tile blit 代码也已被删除。

详情：Raspberry Pi OpenGL Driver Seeing Faster Blit Support Come Mesa 21.0

Xorg

XWayland 21.1 将从 X.Org Server 中剥离出来

近年来，X.Org Server 几乎已经停止更新，但是 Red Hat / Fedora 仍然希望发布对 XWayland 的支持。Red Hat 工程师们目前已经开始着手搭建 XWayland 的独立仓库，这些仓库源于同一个 Xorg Server 版本库，不过删除了与 XWayland 无关的代码。

如前所述，Fedora 正在尝试提供独立的 XWayland 包，该包将跟踪 X.Org Server 仓库的更新状态，但不需要为淘汰的功能而更新 X.Org Server，也不需要为 X.Org 进行 upstream 版本管理。
RedHat 的 Michelddänzer 的想法则与此不同，他提出在 X.Org Server 仓库中单独拉出 XWayland 分支进行维护。该提议将把 XWayland 代码从 X.Org Server 的“主分支”中拉出来，抛弃 Autotools 构建系统，取而代之的则是采用 meson 构建系统，并删除与 XWayland 无关的代码（除了保留对 Xvfb 单元测试的支持）。对于那些不需要构建 X.Org Server，或希望找到一个新的 upstream server 的人来说，这将是 XWayland 的唯一选择。XWayland 21.1.0 将作为该分支的第一个版本，不出意外的话，我们将在 2021 年初迎来第一个 XWayland 版本，并将这个包放入 fedora34 中，以提供比 X.Org Server 1.20 更好的 XWayland 支持。

详情：XWayland 21.1 Proposed In Splitting Off Releases From The X.Org Server

Wayland

1. Wayland 1.19 即将发布

自从 Wayland 1.18 于 2020 年 2 月份发布以来，一直没有太多关于 Wayland 1.19 的讨论，因为现阶段的 Wayland 核心功能已经相当成熟和稳定了。不过 Wayland 1.19 的开发工作已经在上个月开始启动了，预计会在今年1月份发布。Wayland 1.19 并不是一个大的更新，但因为它已经积累了近一年的大大小小的修改，刚刚担任发布经理的 Simon Ser 决定在这个月底发布 Wayland 1.19 正式版本。该版本主要变化包括语法和拼写修正，各种文档更新，Meson 构建系统更新，以及各种与协议相关的小更新。如果其它 rc 版本得到保证，Wayland 1.19.0 可能会到2月份发布。另外，1.19 也将成为历史上最后一个支持 GNU Auto-tool 的版本，而 Meson 将成为该项目唯一的构建系统。

详情：Wayland 1.19 Is Set To Come Soon As First Update In Nearly One Year

2. Weston 新增 YUV 测试 demo

一直以来，Weston 的 tests 目录下的测试 demo 都只支持 RGB 图片的显示，不支持 YUV 格式。近日，来自 Collabora 公司的 Pekka Paalanen 填补了这一块的空白，他为 Weston 开发分支提交了一个 YUV 的测试 demo，该 demo 基于 wl_shm 共享内存，将一张256X256的 PNG 图片以 RGB 格式 load 到内存，然后将其分别转换为 YUV420、NV12 和 YUYV 格式的 buffer，最终送给 compositor 做去显示。该 demo 写的非常简单易懂，适合初学者学习。

详情：tests: add yuv-buffer test

3. Collabora: A Wayland driver for Wine

大家都知道，Wine 是安装在 Linux 上的一个虚拟机，专门用来运行 Window 应用程序的。在 Linux 系统上，Wine 目前使用的是 X11 driver 和 X11 display server 接口。在许多现代系统中，Wayland 已经成为主流的 display server 协议，往往还需要一个 XWayland 的特殊 server 在 X11 和 Wayland 协议之间进行转换。虽然这种转换方式可以正常工作，但是它增加了架构的复杂性且降低了系统性能，如果能让 Wine 直接与 Wayland 进行通信，那么这样的系统架构就会简洁高效许多！

经过几个月的努力，Collabora 终于实现了第一个基于 Wayland 协议的 Wine。与 X11 和 win32 等更传统的显示系统相比，Wayland 协议在设计上受到了更多的限制，这给 Wayland 与 Wine 的集成带来了巨大挑战。Wayland 窗口模型不像 X11 那样基于单一的二维平面坐标空间，Wayland 不允许应用程序控制它们在屏幕上的绝对坐标。而 Win32 应用程序则严重依赖这个特性，因此 Wayland 驱动程序使用了一些技巧来处理这些情况，比如临时窗口（菜单、工具提示等）。Wayland driver 目前支持 GDI 和 OpenGL/DirectX应用程序，已经可以访问大量的 Win32 应用程序，如 Firefox、Stellarium、和 GIMP等。目前暂不支持 Vulkan，不过已经有另外一个项目 https://github.com/varmd/wine-wayland/，专注于 Wine Wayland+Vulkan。

博客中还给出了一个视频，用于展示部分 Windows 应用程序在 Weston Compositor 上的运行 Wine Wayland driver 效果，非常有趣。

详情：A Wayland driver for Wine

Vulkan

Khronos：Vulkan SDK、Tools 和 Drivers 已添加对光线追踪的支持

Vulkan SDK 于去年 12 月 15 日发布，支持光线追踪，包括验证层（Validation Layer）。shader 工具、参考代码以及开发指南也同时升级，以便能够支持 Vulkan Ray Tracing，而驱动程序则由 GPU Vendor 厂商提供。

以下摘自 Beaverton 在 Khronos 官网发表的文章：

今天，Khronos 宣布 LunarG 发布了详细软件开发工具包 (SDK) 版本 1.2.162.0，完全支持新的光线追踪扩展 API，包括升级 GLSL 验证层和集成 HLSL/SPIR-V shader 工具链。Khronos 的开源 Vulkan Samples 和 Vulkan Guide 已经更新，用于演示光线追踪技术。最后，随着 AMD 和 NVIDIA 产品驱动程序的推出，开发人员现在可以轻松地将 Vulkan 光线追踪集成到他们的应用程序中。

Khronos 在 2020 年 11 月发布了最终版 Vulkan 光线追踪 Extension，将光线追踪功能与 Vulkan 的光栅化框架无缝集成，使 Vulkan 成为业界第一个开放、跨厂商、跨平台的光线追踪加速标准。Vulkan 光线追踪可使用现有的 GPU 计算或专用光线追踪硬件进行部署。Vulkan SDK 现在集成了开发者所需的所有组件，以方便使用新的光线追踪扩展，如新的着色器工具链，而不需要从多个存储库构建它们，并支持在 SDK 验证层中进行光线追踪的验证。

详情：Vulkan SDK, Tools and Drivers are Ray Tracing Ready

其它

1. RenderDoc 1.11 发布

RenderDoc 1.11 支持从 Linux 到 Windows 到 任天堂 甚至谷歌的 Stadia 等平台，并支持所有主流的图形 API。RenderDoc 1.11 有几个显著的 Bug 修复，包括 crash 修复，用户界面和用户体验增强，API 修改，支持新的 Vulkan 扩展，如 ext_image_robustness / KHR_copy_commands2 / EXT_shader_atomic_float 等等。

详情：RenderDoc 1.11 Released As The Leading Open-Source, Cross-Platform Graphics Debugger

2. KDE: Plasma KWin 如何在不同刷新率的屏上工作, 以及如何在多线程上进行合成任务

摘要：我们经常收到关于 frame schedule 的投诉。特别是，合成操作没有同步到vblank 事件上，丢帧，用不同的刷新率重新绘制屏幕等等。这篇博客将解释为什么会出现这些问题，以及我们打算如何解决这些问题。

详情：KDE Plasma’s KWin Working On Per-Screen Refresh Rates, Compositing From Multiple Threads