Lines Matching +full:linear +full:- +full:mapping +full:- +full:mode
39 * further describe the buffer's format - for example tiling or compression.
42 * ----------------
56 * vendor-namespaced, and as such the relationship between a fourcc code and a
58 * may preserve meaning - such as number of planes - from the fourcc code,
64 * a modifier: a buffer may match a 64-pixel aligned modifier and a 32-pixel
76 * - Kernel and user-space drivers: for drivers it's important that modifiers
80 * - Higher-level programs interfacing with KMS/GBM/EGL/Vulkan/etc: these users
180 * IEEE 754-2008 binary16 half-precision float
190 * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits
204 …10 fourcc_code('V', 'U', '3', '0') /* Y followed by U then V, 10:10:10. Non-linear modifier only */
208 * 16-xx padding occupy lsb
216 * 16-xx padding occupy lsb except Y410
241 * 1-plane YUV 4:2:0
243 * then V), but the exact Linear layout is undefined.
244 * These formats can only be used with a non-Linear modifier.
274 #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
275 #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
311 /* 3 plane non-subsampled (444) YCbCr
319 /* 3 plane non-subsampled (444) YCrCb
344 #define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) plane…
345 #define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) plane…
351 * Format modifiers describe, typically, a re-ordering or modification
355 * The upper 8 bits of the format modifier are a vendor-id as assigned
374 #define DRM_FORMAT_RESERVED ((1ULL << 56) - 1)
388 * DRM_FORMAT_MOD_GENERIC_* definitions are used to provide vendor-neutral names
390 * compatibility, in cases where a vendor-specific definition already exists and
395 * generic layouts (such as pixel re-ordering), which may have
396 * independently-developed support across multiple vendors.
399 * vendor-specific modifier, a new 'GENERIC' vendor or modifier using vendor
422 * Linear Layout
424 * Just plain linear layout. Note that this is different from no specifying any
426 * which tells the driver to also take driver-internal information into account
435 * implicit, instead it means that the layout is linear. Whether modifiers are
436 * used is out-of-band information carried in an API-specific way (e.g. in a
444 * Intel X-tiling layout
447 * in row-major layout. Within the tile bytes are laid out row-major, with
448 * a platform-dependent stride. On top of that the memory can apply
449 * platform-depending swizzling of some higher address bits into bit6.
453 * cross-driver sharing. It exists since on a given platform it does uniquely
454 * identify the layout in a simple way for i915-specific userspace, which
461 * Intel Y-tiling layout
464 * in row-major layout. Within the tile bytes are laid out in OWORD (16 bytes)
465 * chunks column-major, with a platform-dependent height. On top of that the
466 * memory can apply platform-depending swizzling of some higher address bits
471 * cross-driver sharing. It exists since on a given platform it does uniquely
472 * identify the layout in a simple way for i915-specific userspace, which
479 * Intel Yf-tiling layout
481 * This is a tiled layout using 4Kb tiles in row-major layout.
482 * Within the tile pixels are laid out in 16 256 byte units / sub-tiles which
483 * are arranged in four groups (two wide, two high) with column-major layout.
485 * out as 2x2 column-major.
497 * The main surface will be plane index 0 and must be Y/Yf-tiled,
514 * Intel color control surfaces (CCS) for Gen-12 render compression.
516 * The main surface is Y-tiled and at plane index 0, the CCS is linear and
520 * Y-tile widths.
525 * Intel color control surfaces (CCS) for Gen-12 media compression
527 * The main surface is Y-tiled and at plane index 0, the CCS is linear and
531 * Y-tile widths. For semi-planar formats like NV12, CCS planes follow the
538 * Intel Color Control Surface with Clear Color (CCS) for Gen-12 render
541 * The main surface is Y-tiled and is at plane index 0 whereas CCS is linear
557 * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
559 * Macroblocks are laid in a Z-shape, and each pixel data is following the
564 * - multiple of 128 pixels for the width
565 * - multiple of 32 pixels for the height
567 * For more information: see https://linuxtv.org/downloads/v4l-dvb-apis/re32.html
572 * Tiled, 16 (pixels) x 16 (lines) - sized macroblocks
574 * This is a simple tiled layout using tiles of 16x16 pixels in a row-major
584 * Implementation may be platform and base-format specific.
598 * This is a simple tiled layout using tiles of 4x4 pixels in a row-major
604 * Vivante 64x64 super-tiling layout
606 * This is a tiled layout using 64x64 pixel super-tiles, where each super-tile
607 * contains 8x4 groups of 2x4 tiles of 4x4 pixels (like above) each, all in row-
611 * https://github.com/etnaviv/etna_viv/blob/master/doc/hardware.md#texture-tiling
616 * Vivante 4x4 tiling layout for dual-pipe
620 * compared to the non-split tiled layout.
625 * Vivante 64x64 super-tiling layout for dual-pipe
627 * Same as the 64x64 super-tiling layout, except every second 4x4 pixel tile
629 * therefore halved compared to the non-split super-tiled layout.
643 * Generalized Block Linear layout, used by desktop GPUs starting with NV50/G80,
657 * ---- ----- -----------------------------------------------------------------
661 * DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()-based modifiers.
663 * 4:4 - Must be 1, to indicate block-linear layout. Necessary for
665 * DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()-based modifiers.
667 * 8:5 - Reserved (To support 3D-surfaces with variable log2(depth) block
675 * 11:9 - Reserved (To support 2D-array textures with variable array stride
693 * starting with Fermi GPUs. Additionally, the mapping between page
696 * 0 = Gob Height 8, Fermi - Volta, Tegra K1+ Page Kind mapping
697 * 1 = Gob Height 4, G80 - GT2XX Page Kind mapping
698 * 2 = Gob Height 8, Turing+ Page Kind mapping
703 * page kind and block linear swizzles. This causes the layout of
705 * equivalent mapping on other GPUs in the same system.
707 * 0 = Tegra K1 - Tegra Parker/TX2 Layout.
723 * 55:25 - Reserved for future use. Must be zero.
733 /* To grandfather in prior block linear format modifiers to the above layout,
734 * the page kind "0", which corresponds to "pitch/linear" and hence is unusable
735 * with block-linear layouts, is remapped within drivers to the value 0xfe,
736 * which corresponds to the "generic" kind used for simple single-sample
737 * uncompressed color formats on Fermi - Volta GPUs.
749 * 16Bx2 Block Linear layout, used by Tegra K1 and later
754 * Within a GOB, data is ordered as 16B x 2 lines sectors laid in Z-shape.
797 ((1ULL << __fourcc_mod_broadcom_param_bits) - 1)))
799 ((m) & ~(((1ULL << __fourcc_mod_broadcom_param_bits) - 1) << \
806 * can't do linear). The T format has:
808 * - 64b utiles of pixels in a raster-order grid according to cpp. It's 4x4
811 * - 1k subtiles made of a 4x4 raster-order grid of 64b utiles (so usually
814 * - 4k tiles made of a 2x2 grid of 1k subtiles (so usually 32x32 pixels). On
818 * - an image made of 4k tiles in rows either left-to-right (even rows of 4k
819 * tiles) or right-to-left (odd rows of 4k tiles).
842 * and UV. Some SAND-using hardware stores UV in a separate tiled
882 * the assumption is that a no-XOR tiling modifier will be created.
890 * It provides fine-grained random access and minimizes the amount of data
895 * and different devices or use-cases may support different combinations.
927 * Multiple superblock sizes are only valid for multi-plane YCbCr formats.
944 * AFBC block-split
957 * buffer. This order is the same order used by the header buffer. In this mode
965 * AFBC copy-block restrict
967 * Buffers with this flag must obey the copy-block restriction. The restriction
968 * is such that there are no copy-blocks referring across the border of 8x8
988 * Indicates that the buffer makes use of solid-color blocks, whereby bandwidth
994 * AFBC double-buffer
996 * Indicates that the buffer is allocated in a layout safe for front-buffer
1004 * Indicates that the buffer includes per-superblock content hints.
1008 /* AFBC uncompressed storage mode
1010 * Indicates that the buffer is using AFBC uncompressed storage mode.
1011 * In this mode all superblock payloads in the buffer use the uncompressed
1012 * storage mode, which is usually only used for data which cannot be compressed.
1014 * affects the storage mode of the individual superblocks. Note that even a
1015 * buffer without USM set may use uncompressed storage mode for some or all
1021 * Arm Fixed-Rate Compression (AFRC) modifiers
1025 * reductions in graphics and media use-cases.
1041 * ---------------- ---------------
1052 * ------ ----------------- ------------------
1061 * ----------------------------- --------- ----------------- ------------------
1064 * 16x4 chroma 'V' values, in the 'V' plane of a fully-planar YUV buffer
1065 * ----------------------------- --------- ----------------- ------------------
1068 * 8x8 chroma 'V' values, in the 'V' plane of a fully-planar YUV buffer
1069 * ----------------------------- --------- ----------------- ------------------
1071 * Example: 8x4 chroma pairs in the 'UV' plane of a semi-planar YUV buffer
1072 * ----------------------------- --------- ----------------- ------------------
1075 * ----------------------------- --------- ----------------- ------------------
1094 * this is the only plane, while for semi-planar and fully-planar YUV buffers,
1099 * For semi-planar and fully-planar YUV buffers, this corresponds to the chroma plane(s).
1101 * For single-plane buffers, AFRC_FORMAT_MOD_CU_SIZE_P0 must be specified
1103 * For semi-planar and fully-planar buffers, both AFRC_FORMAT_MOD_CU_SIZE_P0 and
1117 * Indicates if the buffer uses the scanline-optimised layout
1118 * for an AFRC encoded buffer, otherwise, it uses the rotation-optimised layout.
1124 * Arm 16x16 Block U-Interleaved modifier
1136 * This tiling mode is implemented by the VPU found on all Allwinner platforms,
1142 * The pixel order in each tile is linear and the tiles are disposed linearly,
1143 * both in row-major order.
1157 * The underlying storage is considered to be 3 components, 8bit or 10-bit
1159 * - DRM_FORMAT_YUV420_8BIT
1160 * - DRM_FORMAT_YUV420_10BIT
1162 * The first 8 bits of the mode defines the layout, then the following 8 bits
1184 * - a body content organized in 64x32 superblocks with 4096 bytes per
1185 * superblock in default mode.
1186 * - a 32 bytes per 128x64 header block
1198 * In this mode, only the header memory address is needed, thus the
1204 * be accessible by the user-space clients, but only accessible by the
1207 * The user-space clients should expect a failure while trying to mmap
1208 * the DMA-BUF handle returned by the producer.
1215 * Amlogic FBC Memory Saving mode
1218 * boudaries, i.e. 8bit should be stored in this mode to save allocation
1221 * This mode reduces body layout to 3072 bytes per 64x32 superblock with
1233 * - main surface
1236 * - main surface in plane 0
1237 * - DCC surface in plane 1 (RB-aligned, pipe-aligned if DCC_PIPE_ALIGN is set)
1240 * - main surface in plane 0
1241 * - displayable DCC surface in plane 1 (not RB-aligned & not pipe-aligned)
1242 * - pipe-aligned DCC surface in plane 2 (RB-aligned & pipe-aligned)
1244 * For multi-plane formats the above surfaces get merged into one plane for
1248 * ----- ------------------------ ---------------------------------------------
1264 * 55:36 - Reserved for future use, must be zero
1282 * 64K_D for non-32 bpp is the same for GFX9/GFX10/GFX10_RBPLUS and hence has
1305 * one which is not-aligned.