常识 | drm kms 详解

DRM --- direct rendering manager

以下来自维基 general description：

Linux内核已经有了一个名为fbdev的API，用于管理图形适配器的帧缓冲区，但它不能用于处理现代基于gpu的3d加速视频硬件的需求。这些设备通常需要在它们自己的内存中设置和管理一个命令队列，以便将命令分发给GPU，还需要管理该内存中的缓冲区和空闲空间。最初，用户空间程序(如X Server)直接管理这些资源，但它们通常表现得好像它们是唯一能够访问这些资源的程序。当两个或多个程序试图同时控制相同的硬件，并以自己的方式设置其资源时，大多数情况下它们会灾难性地结束

DRM能够允许多个程序共同使用视频硬件资源。DRM获得对GPU的独占访问权，并负责初始化和维护命令队列、内存和任何其他硬件资源。希望使用GPU的程序将请求发送给DRM，后者充当仲裁人并注意避免可能的冲突。

DRM的范围在过去几年里得到了扩展，涵盖了以前由用户空间程序处理的更多功能，如帧缓冲区管理和模式设置、内存共享对象和内存同步。其中一些扩展被赋予了特定的名称，如图形执行管理器(GEM)或内核模式设置(KMS)，但它们实际上是整个内核DRM子系统的一部分。

目前计算机通常包含两个GPU，一个是离散的GPU，一个是集成的GPU，导致了新的问题，如GPU切换，这些问题也需要在DRM层解决。为了匹配英伟达Optimus技术，DRM提供了GPU卸载能力，称为PRIME.

软件架构：

DRM驻留在内核空间中，因此用户空间程序必须使用内核系统调用来请求它的服务。但是，DRM没有定义它自己的系统调用。相反，它遵循Unix“一切都是文件”的原则，通过文件系统名称空间公开gpu，使用/dev层次结构下的设备文件。每一个被DRM检测到的GPU都被称为DRM设备，并创建一个设备文件/dev/driver/cardx(其中X是一个连续的数字)来与它连接。希望与GPU通信的用户空间程序必须打开这个文件并使用ioctl调用与DRM通信。不同的ioctl对应于DRM API的不同功能。

为了方便用户空间程序与DRM子系统的接口，创建了一个名为libdrm的库。这个库只是一个包装器，它为DRM API的每个ioctl以及常量、结构和其他辅助元素提供了用C编写的函数。使用libdrm不仅避免了将内核接口直接暴露给应用程序，而且提供了在程序之间重用和共享代码的通常优点。

DRM由两部分组成：通用的“DRM core”和针对每种支持的硬件类型的特定的“DRM driver”。
DRM core提供了基本框架，不同的DRM驱动程序可以在其中注册，还为用户空间提供了最小的ioctl集，具有通用的、硬件独立的功能。
DRM driver实现API中与硬件相关的部分，具体到它所支持的GPU类型；并提供DRM core未覆盖的剩余ioctl的实现，也可以扩展API，提供附加的ioctl，具有仅在此类硬件上可用的额外功能。当特定的DRM driver提供了扩展API时，libdrm也通过一个额外的库libdrm-driver进行扩展

kms