uapi/drm/drm_fourcc.h

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,
149  * IEEE 754-2008 binary16 half-precision float
167 …10	fourcc_code('V', 'U', '3', '0') /* Y followed by U then V, 10:10:10. Non-linear modifier only */
171  * 16-xx padding occupy lsb
179  * 16-xx padding occupy lsb except Y410
204  * 1-plane YUV 4:2:0
206  * then V), but the exact Linear layout is undefined.
207  * These formats can only be used with a non-Linear modifier.
237 #define DRM_FORMAT_NV24		fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
238 #define DRM_FORMAT_NV42		fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
274 /* 3 plane non-subsampled (444) YCbCr
282 /* 3 plane non-subsampled (444) YCrCb
307 #define DRM_FORMAT_YUV444	fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) plane…
308 #define DRM_FORMAT_YVU444	fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) plane…
314  * Format modifiers describe, typically, a re-ordering or modification
318  * The upper 8 bits of the format modifier are a vendor-id as assigned
338 #define DRM_FORMAT_RESERVED	      ((1ULL << 56) - 1)
352  * DRM_FORMAT_MOD_GENERIC_* definitions are used to provide vendor-neutral names
354  * compatibility, in cases where a vendor-specific definition already exists and
359  * generic layouts (such as pixel re-ordering), which may have
360  * independently-developed support across multiple vendors.
363  * vendor-specific modifier, a new 'GENERIC' vendor or modifier using vendor
386  * Linear Layout
388  * Just plain linear layout. Note that this is different from no specifying any
390  * which tells the driver to also take driver-internal information into account
398  * Intel X-tiling layout
401  * in row-major layout. Within the tile bytes are laid out row-major, with
402  * a platform-dependent stride. On top of that the memory can apply
403  * platform-depending swizzling of some higher address bits into bit6.
407  * cross-driver sharing. It exists since on a given platform it does uniquely
408  * identify the layout in a simple way for i915-specific userspace, which
415  * Intel Y-tiling layout
418  * in row-major layout. Within the tile bytes are laid out in OWORD (16 bytes)
419  * chunks column-major, with a platform-dependent height. On top of that the
420  * memory can apply platform-depending swizzling of some higher address bits
425  * cross-driver sharing. It exists since on a given platform it does uniquely
426  * identify the layout in a simple way for i915-specific userspace, which
433  * Intel Yf-tiling layout
435  * This is a tiled layout using 4Kb tiles in row-major layout.
436  * Within the tile pixels are laid out in 16 256 byte units / sub-tiles which
437  * are arranged in four groups (two wide, two high) with column-major layout.
439  * out as 2x2 column-major.
451  * The main surface will be plane index 0 and must be Y/Yf-tiled,
468  * Intel color control surfaces (CCS) for Gen-12 render compression.
470  * The main surface is Y-tiled and at plane index 0, the CCS is linear and
474  * Y-tile widths.
479  * Intel color control surfaces (CCS) for Gen-12 media compression
481  * The main surface is Y-tiled and at plane index 0, the CCS is linear and
485  * Y-tile widths. For semi-planar formats like NV12, CCS planes follow the
492  * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
494  * Macroblocks are laid in a Z-shape, and each pixel data is following the
499  * - multiple of 128 pixels for the width
500  * - multiple of  32 pixels for the height
502  * For more information: see https://linuxtv.org/downloads/v4l-dvb-apis/re32.html
507  * Tiled, 16 (pixels) x 16 (lines) - sized macroblocks
509  * This is a simple tiled layout using tiles of 16x16 pixels in a row-major
519  * Implementation may be platform and base-format specific.
533  * This is a simple tiled layout using tiles of 4x4 pixels in a row-major
539  * Vivante 64x64 super-tiling layout
541  * This is a tiled layout using 64x64 pixel super-tiles, where each super-tile
542  * contains 8x4 groups of 2x4 tiles of 4x4 pixels (like above) each, all in row-
546  * https://github.com/etnaviv/etna_viv/blob/master/doc/hardware.md#texture-tiling
551  * Vivante 4x4 tiling layout for dual-pipe
555  * compared to the non-split tiled layout.
560  * Vivante 64x64 super-tiling layout for dual-pipe
562  * Same as the 64x64 super-tiling layout, except every second 4x4 pixel tile
564  * therefore halved compared to the non-split super-tiled layout.
578  * Generalized Block Linear layout, used by desktop GPUs starting with NV50/G80,
592  * ----  ----- -----------------------------------------------------------------
596  *             DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()-based modifiers.
598  *  4:4  -     Must be 1, to indicate block-linear layout.  Necessary for
600  *             DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()-based modifiers.
602  *  8:5  -     Reserved (To support 3D-surfaces with variable log2(depth) block
610  * 11:9  -     Reserved (To support 2D-array textures with variable array stride
628  *             starting with Fermi GPUs.  Additionally, the mapping between page
631  *               0 = Gob Height 8, Fermi - Volta, Tegra K1+ Page Kind mapping
632  *               1 = Gob Height 4, G80 - GT2XX Page Kind mapping
633  *               2 = Gob Height 8, Turing+ Page Kind mapping
638  *             page kind and block linear swizzles.  This causes the layout of
640  *             equivalent mapping on other GPUs in the same system.
642  *               0 = Tegra K1 - Tegra Parker/TX2 Layout.
658  * 55:25 -     Reserved for future use.  Must be zero.
668 /* To grandfather in prior block linear format modifiers to the above layout,
669  * the page kind "0", which corresponds to "pitch/linear" and hence is unusable
670  * with block-linear layouts, is remapped within drivers to the value 0xfe,
671  * which corresponds to the "generic" kind used for simple single-sample
672  * uncompressed color formats on Fermi - Volta GPUs.
684  * 16Bx2 Block Linear layout, used by Tegra K1 and later
689  * Within a GOB, data is ordered as 16B x 2 lines sectors laid in Z-shape.
732 	       ((1ULL << __fourcc_mod_broadcom_param_bits) - 1)))
734 	((m) & ~(((1ULL << __fourcc_mod_broadcom_param_bits) - 1) <<	\
741  * can't do linear).  The T format has:
743  * - 64b utiles of pixels in a raster-order grid according to cpp.  It's 4x4
746  * - 1k subtiles made of a 4x4 raster-order grid of 64b utiles (so usually
749  * - 4k tiles made of a 2x2 grid of 1k subtiles (so usually 32x32 pixels).  On
753  * - an image made of 4k tiles in rows either left-to-right (even rows of 4k
754  *   tiles) or right-to-left (odd rows of 4k tiles).
777  * and UV.  Some SAND-using hardware stores UV in a separate tiled
817  * the assumption is that a no-XOR tiling modifier will be created.
825  * It provides fine-grained random access and minimizes the amount of data
830  * and different devices or use-cases may support different combinations.
862  * Multiple superblock sizes are only valid for multi-plane YCbCr formats.
879  * AFBC block-split
892  * buffer. This order is the same order used by the header buffer. In this mode
900  * AFBC copy-block restrict
902  * Buffers with this flag must obey the copy-block restriction. The restriction
903  * is such that there are no copy-blocks referring across the border of 8x8
923  * Indicates that the buffer makes use of solid-color blocks, whereby bandwidth
929  * AFBC double-buffer
931  * Indicates that the buffer is allocated in a layout safe for front-buffer
939  * Indicates that the buffer includes per-superblock content hints.
943 /* AFBC uncompressed storage mode
945  * Indicates that the buffer is using AFBC uncompressed storage mode.
946  * In this mode all superblock payloads in the buffer use the uncompressed
947  * storage mode, which is usually only used for data which cannot be compressed.
949  * affects the storage mode of the individual superblocks. Note that even a
950  * buffer without USM set may use uncompressed storage mode for some or all
956  * Arm 16x16 Block U-Interleaved modifier
968  * This tiling mode is implemented by the VPU found on all Allwinner platforms,
974  * The pixel order in each tile is linear and the tiles are disposed linearly,
975  * both in row-major order.
989  * The underlying storage is considered to be 3 components, 8bit or 10-bit
991  * - DRM_FORMAT_YUV420_8BIT
992  * - DRM_FORMAT_YUV420_10BIT
994  * The first 8 bits of the mode defines the layout, then the following 8 bits
1016  * - a body content organized in 64x32 superblocks with 4096 bytes per
1017  *   superblock in default mode.
1018  * - a 32 bytes per 128x64 header block
1030  * In this mode, only the header memory address is needed, thus the
1036  * be accessible by the user-space clients, but only accessible by the
1039  * The user-space clients should expect a failure while trying to mmap
1040  * the DMA-BUF handle returned by the producer.
1047  * Amlogic FBC Memory Saving mode
1050  * boudaries, i.e. 8bit should be stored in this mode to save allocation
1053  * This mode reduces body layout to 3072 bytes per 64x32 superblock with