101 lines
4.2 KiB
Groff
101 lines
4.2 KiB
Groff
|
.\" Man page generated from reStructuredText.
|
||
|
|
.
|
||
|
|
.
|
||
|
|
.nr rst2man-indent-level 0
|
||
|
|
.
|
||
|
|
.de1 rstReportMargin
|
||
|
|
\\$1 \\n[an-margin]
|
||
|
|
level \\n[rst2man-indent-level]
|
||
|
|
level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
|
||
|
|
-
|
||
|
|
\\n[rst2man-indent0]
|
||
|
|
\\n[rst2man-indent1]
|
||
|
|
\\n[rst2man-indent2]
|
||
|
|
..
|
||
|
|
.de1 INDENT
|
||
|
|
.\" .rstReportMargin pre:
|
||
|
|
. RS \\$1
|
||
|
|
. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
|
||
|
|
. nr rst2man-indent-level +1
|
||
|
|
.\" .rstReportMargin post:
|
||
|
|
..
|
||
|
|
.de UNINDENT
|
||
|
|
. RE
|
||
|
|
.\" indent \\n[an-margin]
|
||
|
|
.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
|
||
|
|
.nr rst2man-indent-level -1
|
||
|
|
.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
|
||
|
|
.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
|
||
|
|
..
|
||
|
|
.TH "DRM" 7 "September 2012" "" "Direct Rendering Manager"
|
||
|
|
.SH NAME
|
||
|
|
drm \- Direct Rendering Manager
|
||
|
|
.SH SYNOPSIS
|
||
|
|
.sp
|
||
|
|
\fB#include <xf86drm.h>\fP
|
||
|
|
.SH DESCRIPTION
|
||
|
|
.sp
|
||
|
|
The \fIDirect Rendering Manager\fP (DRM) is a framework to manage \fIGraphics
|
||
|
|
Processing Units\fP (GPUs). It is designed to support the needs of complex
|
||
|
|
graphics devices, usually containing programmable pipelines well suited
|
||
|
|
to 3D graphics acceleration. Furthermore, it is responsible for memory
|
||
|
|
management, interrupt handling and DMA to provide a uniform interface to
|
||
|
|
applications.
|
||
|
|
.sp
|
||
|
|
In earlier days, the kernel framework was solely used to provide raw
|
||
|
|
hardware access to privileged user\-space processes which implement all
|
||
|
|
the hardware abstraction layers. But more and more tasks were moved into
|
||
|
|
the kernel. All these interfaces are based on \fBioctl\fP(2) commands on
|
||
|
|
the DRM character device. The \fIlibdrm\fP library provides wrappers for these
|
||
|
|
system\-calls and many helpers to simplify the API.
|
||
|
|
.sp
|
||
|
|
When a GPU is detected, the DRM system loads a driver for the detected
|
||
|
|
hardware type. Each connected GPU is then presented to user\-space via a
|
||
|
|
character\-device that is usually available as \fB/dev/dri/card0\fP and can
|
||
|
|
be accessed with \fBopen\fP(2) and \fBclose\fP(2). However, it still
|
||
|
|
depends on the graphics driver which interfaces are available on these
|
||
|
|
devices. If an interface is not available, the syscalls will fail with
|
||
|
|
\fBEINVAL\fP\&.
|
||
|
|
.SS Authentication
|
||
|
|
.sp
|
||
|
|
All DRM devices provide authentication mechanisms. Only a DRM master is
|
||
|
|
allowed to perform mode\-setting or modify core state and only one user
|
||
|
|
can be DRM master at a time. See \fBdrmSetMaster\fP(3) for information
|
||
|
|
on how to become DRM master and what the limitations are. Other DRM users
|
||
|
|
can be authenticated to the DRM\-Master via \fBdrmAuthMagic\fP(3) so they
|
||
|
|
can perform buffer allocations and rendering.
|
||
|
|
.SS Mode\-Setting
|
||
|
|
.sp
|
||
|
|
Managing connected monitors and displays and changing the current modes
|
||
|
|
is called \fIMode\-Setting\fP\&. This is restricted to the current DRM master.
|
||
|
|
Historically, this was implemented in user\-space, but new DRM drivers
|
||
|
|
implement a kernel interface to perform mode\-setting called \fIKernel Mode
|
||
|
|
Setting\fP (KMS). If your hardware\-driver supports it, you can use the KMS
|
||
|
|
API provided by DRM. This includes allocating framebuffers, selecting
|
||
|
|
modes and managing CRTCs and encoders. See \fBdrm\-kms\fP(7) for more.
|
||
|
|
.SS Memory Management
|
||
|
|
.sp
|
||
|
|
The most sophisticated tasks for GPUs today is managing memory objects.
|
||
|
|
Textures, framebuffers, command\-buffers and all other kinds of commands
|
||
|
|
for the GPU have to be stored in memory. The DRM driver takes care of
|
||
|
|
managing all memory objects, flushing caches, synchronizing access and
|
||
|
|
providing CPU access to GPU memory. All memory management is hardware
|
||
|
|
driver dependent. However, two generic frameworks are available that are
|
||
|
|
used by most DRM drivers. These are the \fITranslation Table Manager\fP
|
||
|
|
(TTM) and the \fIGraphics Execution Manager\fP (GEM). They provide generic
|
||
|
|
APIs to create, destroy and access buffers from user\-space. However,
|
||
|
|
there are still many differences between the drivers so driver\-dependent
|
||
|
|
code is still needed. Many helpers are provided in \fIlibgbm\fP (Graphics
|
||
|
|
Buffer Manager) from the \fIMesa\fP project. For more information on DRM
|
||
|
|
memory management, see \fBdrm\-memory\fP(7).
|
||
|
|
.SH REPORTING BUGS
|
||
|
|
.sp
|
||
|
|
Bugs in this manual should be reported to
|
||
|
|
\fI\%https://gitlab.freedesktop.org/mesa/drm/\-/issues\fP\&.
|
||
|
|
.SH SEE ALSO
|
||
|
|
.sp
|
||
|
|
\fBdrm\-kms\fP(7), \fBdrm\-memory\fP(7), \fBdrmSetMaster\fP(3),
|
||
|
|
\fBdrmAuthMagic\fP(3), \fBdrmAvailable\fP(3), \fBdrmOpen\fP(3)
|
||
|
|
.\" Generated by docutils manpage writer.
|
||
|
|
.
|