Lines Matching full:and
9 support for sharing pixel-buffer allocations between processes, devices, and
11 classes; this document details how applications and kernel subsystems should
14 It is written with reference to the DRM subsystem for GPU and display devices,
15 V4L2 for media devices, and also to Vulkan, EGL and Wayland, for userspace
16 support, however any other subsystems should also follow this design and advice.
26 in one or more memory buffers. Has width and height in pixels, pixel
27 format and modifier (implicit or explicit).
41 A piece of memory for storing (parts of) pixel data. Has stride and size
42 in bytes and at least one handle in some API. May contain one or more
46 A two-dimensional array of some or all of an image's color and alpha
51 more color channels values, e.g. R, G and B, or Y, Cb and Cr. May also
57 planes or memory buffers depending on format and modifier.
65 channels R, G, and B. Alpha channel is sometimes counted as a color
69 A description of how pixel data represents the pixel's color and alpha
81 and byte-offset values. Typically used as the byte offset between two
91 Formats and modifiers
96 descriptions (e.g. V4L2 and fbdev), the ``DRM_FORMAT_*`` tokens should be reused
102 co-ordinate in an image, and the color values for that pixel contained within
103 its memory buffers. The number and type of color channels are described:
105 and their locations within the pixel memory, and the relationship between color
109 a single 32-bit value in memory. Alpha, red, green, and blue, color channels are
116 and chroma YUV samples are stored in separate planes, where the chroma plane is
121 samples, and the actual memory storage for the buffer. The most straightforward
124 This is considered the baseline interchange format, and most convenient for CPU
128 making use of tiled access and possibly also compression. For example, the
131 a plane stores pixels (0,0) to (3,3) inclusive, and the second tile in a plane
140 These extended layouts are highly vendor-specific, and even specific to
142 support of modifiers must be explicitly enumerated and negotiated by all users
143 in order to ensure a compatible and optimal pipeline, as discussed below.
146 Dimensions and size
153 component, and 960x540 samples for the U and V components, the overall buffer is
165 with an offset of 0, and the chroma plane's storage follows within the same buffer
188 and modifiers, described together. Within KMS, this is achieved with the
189 ``IN_FORMATS`` property on each DRM plane, listing the supported DRM formats, and
192 `VK_EXT_image_drm_format_modifier`_ extension for Vulkan, and the
209 to pass the ``VkImageUsageFlagBits`` and ``VkImageCreateFlagBits``
212 - for this format, intersect the lists of supported modifiers for both KMS and
217 it intends to use for encoding for the set of modifiers it supports, and
221 buffers in this way, and an alternate strategy must be considered (e.g. using
231 Once userspace has determined an appropriate format, and corresponding list of
238 acceptable modifiers, and the buffer's width and height. Each API may extend
244 allocation, any padding required, and further properties of the underlying
246 memory, whether or not they are physically contiguous, and their cache mode.
251 modifier selected for the buffer, as well as the per-plane offset and stride.
254 the padding expressed through offset, stride, and size.
258 and is not solved by format and modifier tokens.
265 passes these parameters (format, modifier, width, height, and per-plane offset
266 and stride) to an importing API.
270 the luma and chroma buffers combined into a single memory buffer by use of the
272 memory. For this reason, each import and allocation API must provide a separate
275 Each kernel subsystem has its own types and interfaces for buffer management.
281 to a ``dma-buf`` file descriptor, and to import those file descriptors into a
283 contexts, processes, devices, and subsystems.
286 ``DRM_FORMAT_NV12`` buffer. This will result in two memory planes (luma and
289 with the metadata (format, modifier, width, height, per-plane offset and stride)
293 will take the same metadata and convert the dma-buf file descriptors into their
305 such, it has been retrofitted into all of these APIs, and in order to ensure
306 backwards compatibility, support is needed for drivers and userspace which do
310 rendering and KMS for display. It has two entrypoints for allocating buffers:
311 ``gbm_bo_create`` which only takes the format, width, height, and a usage token,
312 and ``gbm_bo_create_with_modifiers`` which extends this with a list of modifiers.
326 pseudo-modifier declares that the layout is not known, and that the driver
333 has the linear layout. Care and attention should be taken to ensure that
345 at all) to declare that explicit modifiers are not supported and must not be
350 that the underlying layout is implementation-defined and that an explicit
360 formed by the producer and all the consumers must be either fully implicit or fully
362 GPU, display, and media, but the media API does not support modifiers, then the
363 user **must not** allocate the buffer with explicit modifiers and attempt to
366 separately and copy between the two buffers.
371 ``gbm_bo_get_modifier`` and then use this modifier as an explicit modifier token
374 When allocating buffers for exchange between different users and modifiers are
381 Any new users - userspace programs and protocols, kernel subsystems, etc -
384 format modifiers to describe the layout in memory, at least width and height for
385 dimensions, and at least offset and stride for each memory plane.