Direct Rendering Manager
|Original author(s)||kernel.org, freedesktop.org, et al.|
|License||GNU General Public License|
The Direct Rendering Manager (DRM) is a device-independent kernel-level device driver that provides support for the Direct Rendering Infrastructure. The Direct Rendering Manager can be compiled into the Linux kernel or loaded via the standard module interface.
||This section is in a list format that may be better presented using prose. (June 2014)|
- The DRM provides synchronized access to the graphics hardware via the use of an optimized two-tiered lock.
- The DRM enforces the DRI security policy for access to the graphics hardware by only allowing authenticated X11 clients access to restricted regions of memory.
- The DRM provides a generic DMA engine, complete with multiple queues and the ability to detect the need for an OpenGL context switch.
- The DRM is extensible via the use of small device-specific modules that rely extensively on the API exported by the DRM module.
It consists of two in-kernel drivers: a generic drm driver, and another which has specific support for the GPUs. This pair of drivers allows a userspace client direct access to the video hardware. The entire DRI system enables hardware accelerated 3D rendering, video decoding as well as GPGPU.
AGP, PCIe and other graphics cards contain an IOMMU called Graphics address remapping table (GART) which can be used to map various pages of system memory into the GPU's address space. The result is that, at any time, an arbitrary (scattered) subset of the system's RAM pages are accessible to the GPU.
The DRM core exports several interfaces to user-space applications, generally intended to be used through corresponding libdrm wrapper functions. In addition, drivers export device-specific interfaces for use by user-space drivers & device-aware applications through ioctls and sysfs files. External interfaces include: memory mapping, context management, DMA operations, AGP management, vblank control, fence management, memory management, and output management.
KMS driver (Kernel mode setting)
The KMS driver is the component which is solely responsible for the mode setting. It is the device driver for a display controller, and it can be distinguished from the device driver of a rendering accelerator. Due to the fact that dies of modern the GPU found on graphics cards for desktop computers integrate "processing logic", "display controller" and "hardware video acceleration" SIP cores, non-technical people don't distinguish between these three very different components. SoCs on the other hand, regularly mix SIP from different developers, and e.g. ARM's Mali SIP does not feature a display controller. For historical reasons, the DRM and the KMS of the Linux kernel were amalgamated into one component. They were split in 2013 for technical reasons.
The video Embedded Linux Conference 2013 – Anatomy of an Embedded KMS driver on YouTube explains what a KMS driver is.
Support for a multi-monitor set-up is of course an ability of the display controller. For example, AMD's display controllers since the Radeon HD 5000 Series, are advertised with the brand "AMD Eyefinity". This new capability of the hardware is supported by AMD's proprietary driver. Whether it is also supported by the KMS driver, this section will tell soon.
A render node is a character device that exposes a GPU's off-screen rendering and GPGPU capabilities to unprivileged programs, without exposing any display manipulation access. This is the first step in of an effort to decouple the kernel's interfaces for GPUs and display controllers from the obsolete notion of a graphics card. Coincidentally, unprivileged off-screen rendering is presumed by both Wayland and Mir display protocols — only the compositor is entitled to send its output to a display, and rendering on behalf of client programs is outside the scope of these protocols.
Patches for universal plane were submitted by Intel's Matthew. D. Roper in May 2014. The idea behind universal plane is to expose all types of hardware planes to userspace via one consistent Kernel–user space API. Universal plane brings framebuffers (primary planes), overlays (secondary planes) and cursors (cursor planes) together under the same API. No more type specific ioctls, but common ioctls shared by them all. 
Universal plane prepares the way for Atomic mode setting and nuclear pageflip.
As of August 2013, the kernel component of the freedreno driver mainly authored by Rob Clark for Qualcomm's Adreno GPU family, called MSM driver, has been accepted into mainline, and has been available since Linux kernel 3.12.
In Linux kernel 3.13
- Free and open-source graphics device driver
- Mesa 3D
- Graphics address remapping table (GART)
- Vblank & V-sync
- "Linux kernel/drivers/gpu/drm/README.drm". kernel.org. Retrieved 2014-02-26.
- "Memory management for graphics processors". LWN.net. 2007-11-06. Retrieved 2014-06-25.
- "DRM changes in Linux Kernel 3.11 are huge". Phoronix. 2013-06-30. Retrieved 2014-06-25.
- "Splitting DRM and KMS nodes". David Herrmann. 2013-09-01.
- "Neat drm/i915 stuff for 3.16". 2014-06-10.
- "drm: implement experimental render nodes".
- "drm/i915: Support render nodes".
- "drm/radeon: Support render nodes".
- "drm/nouveau: Support render nodes".
- "Universal plane support". 2014-05-07.
- "From pre-history to beyond the global thermonuclear war". 2014-06-05.
- "/drivers/gpu/drm". kernel.org.
- "Merge the MSM driver from Rob Clark". freedesktop.org. 2013-08-28. Retrieved 2014-06-25.
- "drm/msm for Linux kernel 3.13". freedesktop.org. 2013-10-20.
- "Armada DRM support for Linux kernel 3.13".
- DRM home page
- The Direct Rendering Manager: Kernel Support for the Direct Rendering Infrastructure
- Linux DRM Developer's Guide
- David Herrmann on Splitting DRM and KMS device nodes
- Embedded Linux Conference 2013 - Anatomy of an Embedded KMS driver on YouTube