Lines Matching +full:two +full:- +full:dimensional
1 .. SPDX-License-Identifier: GPL-2.0
2 .. Copyright 2021-2023 Collabora Ltd.
9 support for sharing pixel-buffer allocations between processes, devices, and
12 approach this sharing for two-dimensional image data.
25 Conceptually a two-dimensional array of pixels. The pixels may be stored
30 A span along a single y-axis value, e.g. from co-ordinates (0,100) to
37 A span along a single x-axis value, e.g. from co-ordinates (100,0) to
46 A two-dimensional array of some or all of an image's color and alpha
80 A value that denotes the relationship between pixel-location co-ordinates
81 and byte-offset values. Typically used as the byte offset between two
82 pixels at the start of vertically-consecutive tiling blocks. For linear
83 layouts, the byte offset between two vertically-adjacent pixels. For
84 non-linear formats the stride must be computed in a consistent way, which
85 usually is done as-if the layout was linear.
102 co-ordinate in an image, and the color values for that pixel contained within
104 whether they are RGB or YUV, integer or floating-point, the size of each channel
109 a single 32-bit value in memory. Alpha, red, green, and blue, color channels are
110 available at 8-bit precision per channel, ordered respectively from most to
111 least significant bits in little-endian storage. ``DRM_FORMAT_*`` is not
113 always as described in the format definition, which is usually little-endian.
120 Format modifiers describe a translation mechanism between these per-pixel memory
123 is laid out row-sequentially, from the top-left to the bottom-right corner.
130 are stored in 4x4 blocks arranged in row-major ordering, i.e. the first tile in
140 These extended layouts are highly vendor-specific, and even specific to
141 particular generations or configurations of devices per-vendor. For this reason,
156 The in-memory storage of a buffer is not guaranteed to begin immediately at the
161 added to the base address of the memory storage before performing any per-pixel
169 between two contiguous row. For example, a ``DRM_FORMAT_MOD_LINEAR`` buffer
207 - query KMS for the ``IN_FORMATS`` property for the given plane
208 - query Vulkan for the supported formats for its physical device, making sure
211 - intersect these formats to determine the most appropriate one
212 - for this format, intersect the lists of supported modifiers for both KMS and
233 buffer-allocation interface available at either kernel or userspace level, the
240 than two dimensions, intended usage patterns, etc.
245 memory buffers such as whether they are stored in system or device-specific
248 ``dma-heaps`` API is an effort to address this.
251 modifier selected for the buffer, as well as the per-plane offset and stride.
257 placement within a particular memory area, etc, is out of scope of dma-buf,
265 passes these parameters (format, modifier, width, height, and per-plane offset
271 per-plane offset parameters, or they may be completely separate allocations in
279 To address this, ``dma-buf`` handles are used as the universal interchange for
280 buffers. Subsystem-specific operations are used to export native buffer handles
281 to a ``dma-buf`` file descriptor, and to import those file descriptors into a
282 native buffer handle. dma-buf file descriptors can be transferred between
286 ``DRM_FORMAT_NV12`` buffer. This will result in two memory planes (luma and
288 one dma-buf file descriptor per plane, these descriptors are then sent along
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
296 Having a non-empty intersection of supported modifiers does not guarantee that
304 The concept of modifiers post-dates all of the subsystems mentioned above. As
310 rendering and KMS for display. It has two entrypoints for allocating buffers:
319 implementation-specific: some will internally use tiled layouts which are not
320 CPU-accessible if the implementation decides that is a good idea through
326 pseudo-modifier declares that the layout is not known, and that the driver
331 ``DRM_FORMAT_MOD_INVALID`` is a non-zero value. The modifier value zero is
336 with an out-of-band flag, like in ``DRM_IOCTL_MODE_ADDFB2``.
339 - during enumeration, an interface may return ``DRM_FORMAT_MOD_INVALID``, either
343 - during allocation, a user may supply ``DRM_FORMAT_MOD_INVALID``, either as the
348 - in a post-allocation query, an implementation may return
350 that the underlying layout is implementation-defined and that an explicit
354 - when importing a buffer, the user may supply ``DRM_FORMAT_MOD_INVALID`` as the
366 separately and copy between the two buffers.
379 subject to driver-specific heuristics.
381 Any new users - userspace programs and protocols, kernel subsystems, etc -
382 wishing to exchange buffers must offer interoperability through dma-buf file
387 …ps://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/unstable/linux-dmabuf/linux-dmab…
388 .. _VK_EXT_image_drm_format_modifier: https://registry.khronos.org/vulkan/specs/1.3-extensions/man/…