drm框架简介

1、 DRM简介（Direct Rendering Manager）

传统linux显示设备驱动开发时，通常使用FB驱动架构，随着显卡性能升级：显示覆盖（菜单层级）、GPU加速、硬件光标，传统FB架构无法很好支持，此外，对于多应用的访问冲突也无法很好控制。在这样的背景下，DRM应用而生。

DRM是linux内核中负责与显卡交互的管理架构，用户空间很方便的利用DRM提供的API，实现3D渲染、视频解码和GPU计算等工作。DRM是DRI(Direct Rendering Infrastructure）框架中的一个部分。

DRI并不是一个软件模块。相反DRI是由一系列的软件模块组成。引入DRI的目的是为了3D图形加速，DRI是一个软件架构，用来协调linux kernel，X windows系统，3D图形硬件以及OpenGL渲染引擎之间的工作。

1.1 DRM发展历史

1999年，Precision Insight公司首次为 XFree86 4.0 Server 开发 DRI 显示框架，用于更好的适配 3DFX 公司显卡，初版DRM代码产出后，接下来的几年时间里，DRM 所支持的显卡列表不断被扩充。

2008年10月，Linux kernel 2.6.27 进行了一次重大的源码重组：DRM 的整套源码被放到了/drivers/gpu/drm/目录下，不同的GPU厂商代码也被放到了各自子目录下。

2014年6月，Atomic API 被添加到Linux 3.16，许多驱动也都转而使用这些新的 API。

2018年，又有10个基于 atomic 框架的 DRM 新增驱动被添加到Linux kernel。

1.2 DRM架构对比FB架构优势

DRM是目前Linux的主流图形显示框架，相比于传统FB架构，DRM允许多个程序同时使用视频硬件资源，管理多个程序的资源请求、访问，综上所述DRM更能适应日益更新的显示硬件，DRM优势主要体现：

DRM原生支持多图层合成，FB原生不支持多层合成。

FB不支持VSYNC、DMA-BUF、异步更新和fence机制，但DRM原生都支持。

DRM统一管理GPU和Display驱动，让软件升级、维护和管理更加方便。

1.3 DRM图形显示框架

DRM检测到的每个GPU都作为DRM设备，并为之创建一个设备文件/dev/dri/cardX与之连接，从整体架构上来看主要分为3个主要部分：

libdrm （接口库）

对底层接口进行封装，向上层提供通用的API接口，主要是对各种IOCTL接口进行封装，便于重用与代码共享。

KMS (Kernel Mode Setting)

正常工作时，需要设置显卡或者图形适配器的模式，主要体现在以下两个方面：

更新画面：显示buffer的切换，多图层的合成方式控制，以及每个图层的显示位置。

设置显示参数：包括分辨率、刷新率、电源状态（休眠唤醒）等。

KMS抽象逻辑

元素	说明
CRTC	对显示buffer 进行扫描产生时序的硬件模块，通常是指 Display Controller。CRTC对内连接 Framebuffer 地址，对外连接 Encoder，会扫描 Framebuffer 上的内容，叠加上 Planes 的内容，最后传给Encoder。在 rockchip 平台是 SOC 内部 VOP(部分文档也称为 LCDC)模块的抽象。
Encoder	负责将CRTC输出的Timing 转换为外部设备需要信号的硬件模块，比如 HDMI 转换器，LVDS转换器，MIPI/DSI 转换器等
Connector	连接物理显示设备的连接器，比如 HDMI接口，LVDS 接口等，通常和 Encoder 绑定在一起
Plane	硬件图层，一个 plane 对应于一张显示buffer,有的 显示设备支持多图层显示（overlay mode),但所有的Display Controller至少要有1个plane
FB	Framebuffer ，单个图层的显示buffer,对应于一段显存
VBlank	软件和硬件的同步机制，LCD时序中两帧之间的垂直消隐区，软件通常使用硬件VSYNC来实现
Property	DRM 中用于设置显示参数的数据结构，所有设置到显示设备的参数都可以抽象为 property
Dump	表示连续物理内存，基于kernel中通用CMA API实现，多用于小分辨率简单场景
Prime	连续、非连续物理内存都支持，基于DMA-BUF机制，可以实现buffer共享，多用于大内存复杂场景
Fence	Buffer 之间的同步机制，基于内核dma_fence机制实现，用于防止显示内容出现异步问题

GEM (Graphics Execution Manager)

提供内存管理方法，主要负责显示buffer的分配和释放