Linux Graphics 周刊（第 2 期）

最新推荐文章于 2024-08-10 01:03:11 发布

何小龙

最新推荐文章于 2024-08-10 01:03:11 发布

阅读量2.8k

点赞数 1

分类专栏： Linux Graphics 周刊文章标签： android linux vulkan

本文链接：https://blog.csdn.net/hexiaolong2009/article/details/108229714

版权

Linux Graphics 周刊专栏收录该内容

10 篇文章 65 订阅

订阅专栏

(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/20200814173131.2803002-1-minchan@kernel.org），即每次分配内存不再是以单个 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