Linux drm_syncobj机制原理与应用方式
作者：DeeplyMind
DRM_syncobj是Linux内核中用于GPU同步的抽象,支持二元与时间线语义,提供高效用户接口,实现跨进程/驱动同步,满足现代图形API如Vulkan的复杂需求
1. 概念
1.1 什么是 drm_syncobj
DRM Sync Object（同步对象，简称 syncobj）是 Linux DRM（Direct Rendering Manager）子系统中用于 GPU 命令同步的内核抽象。
syncobj 的设计初衷是为用户空间提供一种高效、灵活的 GPU 任务同步原语，主要用于显卡驱动和用户空间（如 Vulkan、OpenCL、OpenGL 等）之间的同步需求。
syncobj 的核心作用是包装一个指向 dma_fence 结构体的指针（可能为 NULL），通过 ioctl 接口，用户空间可以创建、销毁、导入、导出、信号、重置、等待等操作 syncobj，从而实现 GPU 命令流的精细同步。
1.2 设计目标
- 跨进程/跨驱动共享：syncobj 可通过 fd 句柄在进程间传递，实现多进程/多驱动同步。
- 支持二元与时间线语义：既可作为简单的“signaled/unsignal”二元同步原语，也可作为时间线（timeline）同步原语，支持多点同步。
- 高效用户空间接口：通过一组 ioctl，用户空间可灵活操作 syncobj，满足 Vulkan 等现代图形 API 的同步需求。
drm_syncobj是为用户空间设计的，因此内核自身不会使用该结构体，只有各家的GPU驱动才会使用。
1.3 主要数据结构
| 结构体名称 | 作用说明 |
|---|---|
| struct drm_syncobj | 同步对象的核心结构，包含 fence 指针、回调链表、事件链表、锁等。 |
| struct dma_fence | 底层同步原语，表示 GPU 命令完成的信号。 |
| struct dma_fence_chain | 时间线模式下的链式 fence，支持多点同步。 |
| struct syncobj_wait_entry | 用于等待的辅助结构。 |
| struct syncobj_eventfd_entry | 用于事件通知的辅助结构。 |
2. 原理分析
2.1 同步机制原理
2.1.1 二元同步对象
在二元模式下，syncobj 通过维护一个可替换的 fence 指针实现同步状态管理。
该设计充分利用了 dma_fence 的单向状态特性（不可逆的"已信号"状态，dma_fence的单向状态转换决定了的单个dma_fence是短命的），通过动态创建并替换 fence 对象实现状态重置。
- 信号操作：驱动创建新的已信号
dma_fence替换原对象。 - 重置操作：驱动创建新的未信号
dma_fence替换原对象。
2.1.2 时间线同步对象
- 时间线模式下，syncobj 维护一个
dma_fence_chain，每个链节点代表一个时间点（seqno）。 - GPU 驱动可在任意时间点插入新的 fence，实现多点同步。
- 用户空间可针对任意时间点进行信号、等待、查询等操作。
2.1.3 等待机制
- 主机侧等待：通过
DRM_IOCTL_SYNCOBJ_WAIT或DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT，用户空间可等待一个或多个 syncobj 的 fence 被信号。支持等待全部或任意一个、超时、deadline、等待 fence 出现等多种模式。 - 事件通知：通过 eventfd 机制，用户空间可注册事件，当 syncobj 被信号时，eventfd 被唤醒，便于集成到事件循环。
2.1.4 导入/导出机制
- fd 句柄导入/导出：syncobj 可导出为 fd，在进程间传递，所有 fd 共享同一个底层 syncobj。
- sync_file 导入/导出：可将 syncobj 当前 fence 导出为 sync_file，或从 sync_file 导入 fence 到 syncobj。sync_file 是 Linux 通用的同步文件描述符，便于与其他子系统（如 dma-buf）集成。
2.2 典型流程
- 用户空间通过 ioctl 创建 syncobj，获得 handle 或 fd。
- GPU 驱动在提交命令时，将 fence 绑定到 syncobj。
- a. 用户空间可通过 ioctl 等待 syncobj 被信号，或查询其状态。b. GPU执行完命令后，发中断，中断处理中singal syncobj。a和b两个过程是同时进行的，看哪个先完成。
- syncobj 可在进程间传递，实现跨进程同步。
- 时间线模式下，用户空间和驱动可在任意时间点操作 syncobj，实现复杂同步场景。
这个典型使用流程是理解syncobj的关键，记住一点：syncobj是用户空间使用的。
3. 实现
syncobj 支持如下基本操作：
| 操作类型 | 说明 |
|---|---|
| 创建与销毁 | 分配和释放同步对象资源 |
| 信号与重置 | 设置同步对象为已完成或未完成状态 |
| 等待 | 阻塞或非阻塞地等待同步对象变为已完成状态 |
| 导入与导出 | 将同步对象的状态在进程间传递，实现跨进程同步 |
| timeline 操作 | 部分驱动支持 timeline syncobj，可以表示多个时间点的同步状态 |
3.1 接口分类和功能
| 分类 | 主要接口/函数名 | 功能说明 |
|---|---|---|
| 创建与销毁 | drm_syncobj_create | 分配并初始化 syncobj，支持初始信号状态（SIGNALED） |
| drm_syncobj_destroy | 释放 syncobj，清理所有引用和资源 | |
| 导入与导出 | drm_syncobj_get_handle / drm_syncobj_get_fd | 将 syncobj 导出为 handle 或 fd |
| drm_syncobj_handle_to_fd / drm_syncobj_fd_to_handle | fd 与 handle 互转，支持跨进程共享 | |
| drm_syncobj_import_sync_file_fence / drm_syncobj_export_sync_file | 与 sync_file 互操作，便于与 dma-buf 等子系统集成 | |
| 信号与重置 | drm_syncobj_replace_fence | 替换 syncobj 的 fence，实现信号或重置 |
| drm_syncobj_assign_null_handle | 分配一个已信号的 stub fence，实现“信号”操作 | |
| drm_syncobj_signal_ioctl / drm_syncobj_reset_ioctl | 用户空间 ioctl 接口，批量信号或重置 syncobj | |
| 时间线操作 | drm_syncobj_add_point | 在时间线 syncobj 上添加新的时间点（fence_chain） |
| drm_syncobj_transfer_to_timeline / drm_syncobj_transfer_to_binary | 在不同 syncobj 间转移时间点或 fence，实现复杂同步场景 | |
| drm_syncobj_timeline_signal_ioctl | 用户空间 ioctl，批量信号时间线上的多个点 | |
| drm_syncobj_query_ioctl | 查询时间线 syncobj 的状态，支持查询最后提交点或最后信号点 | |
| 等待与事件通知 | drm_syncobj_array_wait_timeout | 核心等待实现，支持多种等待模式（全部、任意、超时、deadline等） |
| drm_syncobj_eventfd_ioctl | 注册 eventfd，当 syncobj 被信号时唤醒用户空间 | |
| dma_fence_add_callback | fence 信号时的唤醒和事件通知回调机制 | |
| 内存与引用管理 | kref 引用计数机制 | syncobj 通过引用计数管理生命周期，确保多进程/多 fd 安全 |
| 严格引用管理 | 所有导入/导出、等待、事件等操作均严格管理引用，防止资源泄漏 |
3.2 关键代码分析
这部分专门出一篇博文介绍，还在编写中....
4. 为什么设计 drm_syncobj
下面是 drm_syncobj 与 dma_resv、sync_file 的对比分析，并说明 drm_syncobj 的设计初衷和优势。
| 对比项 | dma_resv(内核使用) | sync_file | drm_syncobj（设计初衷与优势） |
|---|---|---|---|
| 主要用途 | 内核对象，管理 dma-buf 的同步（读/写 fence） | 用户空间同步文件，导出/传递 fence | 用户空间可管理的同步对象，专为 GPU/Vulkan 设计 |
| 用户空间接口 | 无直接接口，驱动内部使用 | 通过 fd 传递，支持 epoll/select | 丰富 ioctl 接口，支持创建、导入、导出、信号、等待 |
| 跨进程/驱动 | 仅限 dma-buf 相关驱动间 | 可跨进程传递，但只封装单个 fence | 可跨进程/驱动共享，支持 timeline 多点同步 |
| 时间线支持 | 不支持，只有读/写二元 fence | 不支持，单一 fence | 支持 timeline fence_chain，满足 Vulkan timeline |
| 事件通知 | 无 | 支持 eventfd | 支持 eventfd，且可针对 timeline 任意点 |
| 资源管理 | 内核自动管理 | 用户空间 fd 管理，生命周期与 fd 绑定 | 引用计数（kref），fd/handle均可安全管理 |
| 设计初衷 | dma-buf 内核同步，面向驱动开发 | 通用 fence 导出/传递，面向用户空间 | 面向 GPU/Vulkan 用户空间同步，灵活高效 |
| 典型应用场景 | 显存缓冲区同步，驱动内部 | 用户空间异步等待、跨进程同步 | Vulkan fence/semaphore、跨进程/驱动 GPU 协作 |
- 满足现代图形 API（如 Vulkan）的同步需求：Vulkan 需要 timeline semaphore、跨进程/驱动同步、事件通知等高级功能，dma_resv/sync_file 无法满足。
- 用户空间可控：drm_syncobj 提供丰富的 ioctl 接口，用户空间可灵活创建、管理、导入、导出、等待、信号同步对象。
- 支持 timeline fence：drm_syncobj 支持多点同步，适配 Vulkan timeline semaphore，远超 sync_file 的单点能力。
- 跨进程/驱动协作：通过 fd/handle 机制，drm_syncobj 可在多进程、多驱动间安全共享和同步。
- 高效事件通知：集成 eventfd，便于用户空间异步编程和事件循环。
drm_syncobj 是为现代 GPU 用户空间同步场景量身定制的内核抽象，弥补了 dma_resv/sync_file 在灵活性、扩展性和用户空间接口上的不足。
用户态的应用接口封装在libdrm中，具体实现分析见：Linux libdrm 中 drm_syncobj的实现原理。这两篇对照着看，基本上是一一对应。
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。