1DRM-MEMORY(7) Direct Rendering Manager DRM-MEMORY(7)
2
6 drm-memory, drm-mm, drm-gem, drm-ttm - DRM Memory Management
7
9 #include <xf86drm.h>
10
12 Many modern high-end GPUs come with their own memory managers. They
13 even include several different caches that need to be synchronized
14 during access. Textures, framebuffers, command buffers and more need to
15 be stored in memory that can be accessed quickly by the GPU. Therefore,
16 memory management on GPUs is highly driver- and hardware-dependent.
17 However, there are several frameworks in the kernel that are used by
19 more than one driver. These can be used for trivial mode-setting
20 without requiring driver-dependent code. But for hardware-accelerated
21 rendering you need to read the manual pages for the driver you want to
22 work with.
23 Dumb-Buffers
25 Almost all in-kernel DRM hardware drivers support an API called
26 Dumb-Buffers. This API allows to create buffers of arbitrary size that
27 can be used for scanout. These buffers can be memory mapped via mmap(2)
28 so you can render into them on the CPU. However, GPU access to these
29 buffers is often not possible. Therefore, they are fine for simple
30 tasks but not suitable for complex compositions and renderings.
31 The DRM_IOCTL_MODE_CREATE_DUMB ioctl can be used to create a dumb
33 buffer. The kernel will return a 32bit handle that can be used to
34 manage the buffer with the DRM API. You can create framebuffers with
35 drmModeAddFB(3) and use it for mode-setting and scanout. To access the
36 buffer, you first need to retrieve the offset of the buffer. The
37 DRM_IOCTL_MODE_MAP_DUMB ioctl requests the DRM subsystem to prepare the
38 buffer for memory-mapping and returns a fake-offset that can be used
39 with mmap(2).
40 The DRM_IOCTL_MODE_CREATE_DUMB ioctl takes as argument a structure of
42 type struct drm_mode_create_dumb:
43 struct drm_mode_create_dumb {
45 __u32 height;
46 __u32 width;
47 __u32 bpp;
48 __u32 flags;
49 __u32 handle;
51 __u32 pitch;
52 __u64 size;
53 };
54 The fields height, width, bpp and flags have to be provided by the
56 caller. The other fields are filled by the kernel with the return
57 values. height and width are the dimensions of the rectangular buffer
58 that is created. bpp is the number of bits-per-pixel and must be a
59 multiple of 8. You most commonly want to pass 32 here. The flags field
60 is currently unused and must be zeroed. Different flags to modify the
61 behavior may be added in the future. After calling the ioctl, the
62 handle, pitch and size fields are filled by the kernel. handle is a
63 32bit gem handle that identifies the buffer. This is used by several
64 other calls that take a gem-handle or memory-buffer as argument. The
65 pitch field is the pitch (or stride) of the new buffer. Most drivers
66 use 32bit or 64bit aligned