| 1 |
|
| 2 | |
| 3 | * Copyright 2011 Intel Corporation
|
| 4 |
|
| 5 |
|
| 6 | #ifndef DRM_FOURCC_H
|
| 7 | #define DRM_FOURCC_H
|
| 8 |
|
| 9 | #include "drm.h"
|
| 10 |
|
| 11 | #if defined(__cplusplus)
|
| 12 | extern "C" {
|
| 13 | #endif
|
| 14 |
|
| 15 | |
| 16 | * DOC: overview
|
| 17 | *
|
| 18 | * In the DRM subsystem, framebuffer pixel formats are described using the
|
| 19 | * fourcc codes defined in `include/uapi/drm/drm_fourcc.h`. In addition to the
|
| 20 | * fourcc code, a Format Modifier may optionally be provided, in order to
|
| 21 | * further describe the buffer's format - for example tiling or compression.
|
| 22 | *
|
| 23 | * Format Modifiers
|
| 24 | * ----------------
|
| 25 | *
|
| 26 | * Format modifiers are used in conjunction with a fourcc code, forming a
|
| 27 | * unique fourcc:modifier pair. This format:modifier pair must fully define the
|
| 28 | * format and data layout of the buffer, and should be the only way to describe
|
| 29 | * that particular buffer.
|
| 30 | *
|
| 31 | * Having multiple fourcc:modifier pairs which describe the same layout should
|
| 32 | * be avoided, as such aliases run the risk of different drivers exposing
|
| 33 | * different names for the same data format, forcing userspace to understand
|
| 34 | * that they are aliases.
|
| 35 | *
|
| 36 | * Format modifiers may change any property of the buffer, including the number
|
| 37 | * of planes and/or the required allocation size. Format modifiers are
|
| 38 | * vendor-namespaced, and as such the relationship between a fourcc code and a
|
| 39 | * modifier is specific to the modifier being used. For example, some modifiers
|
| 40 | * may preserve meaning - such as number of planes - from the fourcc code,
|
| 41 | * whereas others may not.
|
| 42 | *
|
| 43 | * Modifiers must uniquely encode buffer layout. In other words, a buffer must
|
| 44 | * match only a single modifier. A modifier must not be a subset of layouts of
|
| 45 | * another modifier. For instance, it's incorrect to encode pitch alignment in
|
| 46 | * a modifier: a buffer may match a 64-pixel aligned modifier and a 32-pixel
|
| 47 | * aligned modifier. That said, modifiers can have implicit minimal
|
| 48 | * requirements.
|
| 49 | *
|
| 50 | * For modifiers where the combination of fourcc code and modifier can alias,
|
| 51 | * a canonical pair needs to be defined and used by all drivers. Preferred
|
| 52 | * combinations are also encouraged where all combinations might lead to
|
| 53 | * confusion and unnecessarily reduced interoperability. An example for the
|
| 54 | * latter is AFBC, where the ABGR layouts are preferred over ARGB layouts.
|
| 55 | *
|
| 56 | * There are two kinds of modifier users:
|
| 57 | *
|
| 58 | * - Kernel and user-space drivers: for drivers it's important that modifiers
|
| 59 | * don't alias, otherwise two drivers might support the same format but use
|
| 60 | * different aliases, preventing them from sharing buffers in an efficient
|
| 61 | * format.
|
| 62 | * - Higher-level programs interfacing with KMS/GBM/EGL/Vulkan/etc: these users
|
| 63 | * see modifiers as opaque tokens they can check for equality and intersect.
|
| 64 | * These users mustn't need to know to reason about the modifier value
|
| 65 | * (i.e. they are not expected to extract information out of the modifier).
|
| 66 | *
|
| 67 | * Vendors should document their modifier usage in as much detail as
|
| 68 | * possible, to ensure maximum compatibility across devices, drivers and
|
| 69 | * applications.
|
| 70 | *
|
| 71 | * The authoritative list of format modifier codes is found in
|
| 72 | * `include/uapi/drm/drm_fourcc.h`
|
| 73 | *
|
| 74 | * Open Source User Waiver
|
| 75 | * -----------------------
|
| 76 | *
|
| 77 | * Because this is the authoritative source for pixel formats and modifiers
|
| 78 | * referenced by GL, Vulkan extensions and other standards and hence used both
|
| 79 | * by open source and closed source driver stacks, the usual requirement for an
|
| 80 | * upstream in-kernel or open source userspace user does not apply.
|
| 81 | *
|
| 82 | * To ensure, as much as feasible, compatibility across stacks and avoid
|
| 83 | * confusion with incompatible enumerations stakeholders for all relevant driver
|
| 84 | * stacks should approve additions.
|
| 85 |
|
| 86 |
|
| 87 | #define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
|
| 88 | ((__u32)(c) << 16) | ((__u32)(d) << 24))
|
| 89 |
|
| 90 | #define DRM_FORMAT_BIG_ENDIAN (1U<<31)
|
| 91 |
|
| 92 |
|
| 93 | #define DRM_FORMAT_INVALID 0
|
| 94 |
|
| 95 |
|
| 96 | #define DRM_FORMAT_C1 fourcc_code('C', '1', ' ', ' ')
|
| 97 | #define DRM_FORMAT_C2 fourcc_code('C', '2', ' ', ' ')
|
| 98 | #define DRM_FORMAT_C4 fourcc_code('C', '4', ' ', ' ')
|
| 99 | #define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ')
|
| 100 |
|
| 101 |
|
| 102 | #define DRM_FORMAT_D1 fourcc_code('D', '1', ' ', ' ')
|
| 103 |
|
| 104 |
|
| 105 | #define DRM_FORMAT_D2 fourcc_code('D', '2', ' ', ' ')
|
| 106 |
|
| 107 |
|
| 108 | #define DRM_FORMAT_D4 fourcc_code('D', '4', ' ', ' ')
|
| 109 |
|
| 110 |
|
| 111 | #define DRM_FORMAT_D8 fourcc_code('D', '8', ' ', ' ')
|
| 112 |
|
| 113 |
|
| 114 | #define DRM_FORMAT_R1 fourcc_code('R', '1', ' ', ' ')
|
| 115 |
|
| 116 |
|
| 117 | #define DRM_FORMAT_R2 fourcc_code('R', '2', ' ', ' ')
|
| 118 |
|
| 119 |
|
| 120 | #define DRM_FORMAT_R4 fourcc_code('R', '4', ' ', ' ')
|
| 121 |
|
| 122 |
|
| 123 | #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ')
|
| 124 |
|
| 125 |
|
| 126 | #define DRM_FORMAT_R10 fourcc_code('R', '1', '0', ' ')
|
| 127 |
|
| 128 |
|
| 129 | #define DRM_FORMAT_R12 fourcc_code('R', '1', '2', ' ')
|
| 130 |
|
| 131 |
|
| 132 | #define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ')
|
| 133 |
|
| 134 |
|
| 135 | #define DRM_FORMAT_RG88 fourcc_code('R', 'G', '8', '8')
|
| 136 | #define DRM_FORMAT_GR88 fourcc_code('G', 'R', '8', '8')
|
| 137 |
|
| 138 |
|
| 139 | #define DRM_FORMAT_RG1616 fourcc_code('R', 'G', '3', '2')
|
| 140 | #define DRM_FORMAT_GR1616 fourcc_code('G', 'R', '3', '2')
|
| 141 |
|
| 142 |
|
| 143 | #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8')
|
| 144 | #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8')
|
| 145 |
|
| 146 |
|
| 147 | #define DRM_FORMAT_XRGB4444 fourcc_code('X', 'R', '1', '2')
|
| 148 | #define DRM_FORMAT_XBGR4444 fourcc_code('X', 'B', '1', '2')
|
| 149 | #define DRM_FORMAT_RGBX4444 fourcc_code('R', 'X', '1', '2')
|
| 150 | #define DRM_FORMAT_BGRX4444 fourcc_code('B', 'X', '1', '2')
|
| 151 |
|
| 152 | #define DRM_FORMAT_ARGB4444 fourcc_code('A', 'R', '1', '2')
|
| 153 | #define DRM_FORMAT_ABGR4444 fourcc_code('A', 'B', '1', '2')
|
| 154 | #define DRM_FORMAT_RGBA4444 fourcc_code('R', 'A', '1', '2')
|
| 155 | #define DRM_FORMAT_BGRA4444 fourcc_code('B', 'A', '1', '2')
|
| 156 |
|
| 157 | #define DRM_FORMAT_XRGB1555 fourcc_code('X', 'R', '1', '5')
|
| 158 | #define DRM_FORMAT_XBGR1555 fourcc_code('X', 'B', '1', '5')
|
| 159 | #define DRM_FORMAT_RGBX5551 fourcc_code('R', 'X', '1', '5')
|
| 160 | #define DRM_FORMAT_BGRX5551 fourcc_code('B', 'X', '1', '5')
|
| 161 |
|
| 162 | #define DRM_FORMAT_ARGB1555 fourcc_code('A', 'R', '1', '5')
|
| 163 | #define DRM_FORMAT_ABGR1555 fourcc_code('A', 'B', '1', '5')
|
| 164 | #define DRM_FORMAT_RGBA5551 fourcc_code('R', 'A', '1', '5')
|
| 165 | #define DRM_FORMAT_BGRA5551 fourcc_code('B', 'A', '1', '5')
|
| 166 |
|
| 167 | #define DRM_FORMAT_RGB565 fourcc_code('R', 'G', '1', '6')
|
| 168 | #define DRM_FORMAT_BGR565 fourcc_code('B', 'G', '1', '6')
|
| 169 |
|
| 170 |
|
| 171 | #define DRM_FORMAT_RGB888 fourcc_code('R', 'G', '2', '4')
|
| 172 | #define DRM_FORMAT_BGR888 fourcc_code('B', 'G', '2', '4')
|
| 173 |
|
| 174 |
|
| 175 | #define DRM_FORMAT_XRGB8888 fourcc_code('X', 'R', '2', '4')
|
| 176 | #define DRM_FORMAT_XBGR8888 fourcc_code('X', 'B', '2', '4')
|
| 177 | #define DRM_FORMAT_RGBX8888 fourcc_code('R', 'X', '2', '4')
|
| 178 | #define DRM_FORMAT_BGRX8888 fourcc_code('B', 'X', '2', '4')
|
| 179 |
|
| 180 | #define DRM_FORMAT_ARGB8888 fourcc_code('A', 'R', '2', '4')
|
| 181 | #define DRM_FORMAT_ABGR8888 fourcc_code('A', 'B', '2', '4')
|
| 182 | #define DRM_FORMAT_RGBA8888 fourcc_code('R', 'A', '2', '4')
|
| 183 | #define DRM_FORMAT_BGRA8888 fourcc_code('B', 'A', '2', '4')
|
| 184 |
|
| 185 | #define DRM_FORMAT_XRGB2101010 fourcc_code('X', 'R', '3', '0')
|
| 186 | #define DRM_FORMAT_XBGR2101010 fourcc_code('X', 'B', '3', '0')
|
| 187 | #define DRM_FORMAT_RGBX1010102 fourcc_code('R', 'X', '3', '0')
|
| 188 | #define DRM_FORMAT_BGRX1010102 fourcc_code('B', 'X', '3', '0')
|
| 189 |
|
| 190 | #define DRM_FORMAT_ARGB2101010 fourcc_code('A', 'R', '3', '0')
|
| 191 | #define DRM_FORMAT_ABGR2101010 fourcc_code('A', 'B', '3', '0')
|
| 192 | #define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0')
|
| 193 | #define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0')
|
| 194 |
|
| 195 |
|
| 196 | #define DRM_FORMAT_RGB161616 fourcc_code('R', 'G', '4', '8')
|
| 197 | #define DRM_FORMAT_BGR161616 fourcc_code('B', 'G', '4', '8')
|
| 198 |
|
| 199 |
|
| 200 | #define DRM_FORMAT_XRGB16161616 fourcc_code('X', 'R', '4', '8')
|
| 201 | #define DRM_FORMAT_XBGR16161616 fourcc_code('X', 'B', '4', '8')
|
| 202 |
|
| 203 | #define DRM_FORMAT_ARGB16161616 fourcc_code('A', 'R', '4', '8')
|
| 204 | #define DRM_FORMAT_ABGR16161616 fourcc_code('A', 'B', '4', '8')
|
| 205 |
|
| 206 | |
| 207 | * Half-Floating point - 16b/component
|
| 208 | * IEEE 754-2008 binary16 half-precision float
|
| 209 | * [15:0] sign:exponent:mantissa 1:5:10
|
| 210 |
|
| 211 | #define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H')
|
| 212 | #define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H')
|
| 213 |
|
| 214 | #define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H')
|
| 215 | #define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H')
|
| 216 |
|
| 217 | #define DRM_FORMAT_R16F fourcc_code('R', ' ', ' ', 'H')
|
| 218 | #define DRM_FORMAT_GR1616F fourcc_code('G', 'R', ' ', 'H')
|
| 219 | #define DRM_FORMAT_BGR161616F fourcc_code('B', 'G', 'R', 'H')
|
| 220 |
|
| 221 | |
| 222 | * Floating point - 32b/component
|
| 223 | * IEEE 754-2008 binary32 float
|
| 224 | * [31:0] sign:exponent:mantissa 1:8:23
|
| 225 |
|
| 226 | #define DRM_FORMAT_R32F fourcc_code('R', ' ', ' ', 'F')
|
| 227 | #define DRM_FORMAT_GR3232F fourcc_code('G', 'R', ' ', 'F')
|
| 228 | #define DRM_FORMAT_BGR323232F fourcc_code('B', 'G', 'R', 'F')
|
| 229 | #define DRM_FORMAT_ABGR32323232F fourcc_code('A', 'B', '8', 'F')
|
| 230 |
|
| 231 | |
| 232 | * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits
|
| 233 | * of unused padding per component:
|
| 234 |
|
| 235 | #define DRM_FORMAT_AXBXGXRX106106106106 fourcc_code('A', 'B', '1', '0')
|
| 236 |
|
| 237 |
|
| 238 | #define DRM_FORMAT_YUYV fourcc_code('Y', 'U', 'Y', 'V')
|
| 239 | #define DRM_FORMAT_YVYU fourcc_code('Y', 'V', 'Y', 'U')
|
| 240 | #define DRM_FORMAT_UYVY fourcc_code('U', 'Y', 'V', 'Y')
|
| 241 | #define DRM_FORMAT_VYUY fourcc_code('V', 'Y', 'U', 'Y')
|
| 242 |
|
| 243 | #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U', 'V')
|
| 244 | #define DRM_FORMAT_AVUY8888 fourcc_code('A', 'V', 'U', 'Y')
|
| 245 | #define DRM_FORMAT_XYUV8888 fourcc_code('X', 'Y', 'U', 'V')
|
| 246 | #define DRM_FORMAT_XVUY8888 fourcc_code('X', 'V', 'U', 'Y')
|
| 247 | #define DRM_FORMAT_VUY888 fourcc_code('V', 'U', '2', '4')
|
| 248 | #define DRM_FORMAT_VUY101010 fourcc_code('V', 'U', '3', '0')
|
| 249 | #define DRM_FORMAT_XVUY2101010 fourcc_code('X', 'Y', '3', '0')
|
| 250 |
|
| 251 | |
| 252 | * packed Y2xx indicate for each component, xx valid data occupy msb
|
| 253 | * 16-xx padding occupy lsb
|
| 254 |
|
| 255 | #define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0')
|
| 256 | #define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2')
|
| 257 | #define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6')
|
| 258 |
|
| 259 | |
| 260 | * packed Y4xx indicate for each component, xx valid data occupy msb
|
| 261 | * 16-xx padding occupy lsb except Y410
|
| 262 |
|
| 263 | #define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0')
|
| 264 | #define DRM_FORMAT_Y412 fourcc_code('Y', '4', '1', '2')
|
| 265 | #define DRM_FORMAT_Y416 fourcc_code('Y', '4', '1', '6')
|
| 266 |
|
| 267 | #define DRM_FORMAT_XVYU2101010 fourcc_code('X', 'V', '3', '0')
|
| 268 | #define DRM_FORMAT_XVYU12_16161616 fourcc_code('X', 'V', '3', '6')
|
| 269 | #define DRM_FORMAT_XVYU16161616 fourcc_code('X', 'V', '4', '8')
|
| 270 |
|
| 271 | |
| 272 | * packed YCbCr420 2x2 tiled formats
|
| 273 | * first 64 bits will contain Y,Cb,Cr components for a 2x2 tile
|
| 274 |
|
| 275 |
|
| 276 | #define DRM_FORMAT_Y0L0 fourcc_code('Y', '0', 'L', '0')
|
| 277 |
|
| 278 | #define DRM_FORMAT_X0L0 fourcc_code('X', '0', 'L', '0')
|
| 279 |
|
| 280 |
|
| 281 | #define DRM_FORMAT_Y0L2 fourcc_code('Y', '0', 'L', '2')
|
| 282 |
|
| 283 | #define DRM_FORMAT_X0L2 fourcc_code('X', '0', 'L', '2')
|
| 284 |
|
| 285 | |
| 286 | * 1-plane YUV 4:2:0
|
| 287 | * In these formats, the component ordering is specified (Y, followed by U
|
| 288 | * then V), but the exact Linear layout is undefined.
|
| 289 | * These formats can only be used with a non-Linear modifier.
|
| 290 |
|
| 291 | #define DRM_FORMAT_YUV420_8BIT fourcc_code('Y', 'U', '0', '8')
|
| 292 | #define DRM_FORMAT_YUV420_10BIT fourcc_code('Y', 'U', '1', '0')
|
| 293 |
|
| 294 | |
| 295 | * 2 plane RGB + A
|
| 296 | * index 0 = RGB plane, same format as the corresponding non _A8 format has
|
| 297 | * index 1 = A plane, [7:0] A
|
| 298 |
|
| 299 | #define DRM_FORMAT_XRGB8888_A8 fourcc_code('X', 'R', 'A', '8')
|
| 300 | #define DRM_FORMAT_XBGR8888_A8 fourcc_code('X', 'B', 'A', '8')
|
| 301 | #define DRM_FORMAT_RGBX8888_A8 fourcc_code('R', 'X', 'A', '8')
|
| 302 | #define DRM_FORMAT_BGRX8888_A8 fourcc_code('B', 'X', 'A', '8')
|
| 303 | #define DRM_FORMAT_RGB888_A8 fourcc_code('R', '8', 'A', '8')
|
| 304 | #define DRM_FORMAT_BGR888_A8 fourcc_code('B', '8', 'A', '8')
|
| 305 | #define DRM_FORMAT_RGB565_A8 fourcc_code('R', '5', 'A', '8')
|
| 306 | #define DRM_FORMAT_BGR565_A8 fourcc_code('B', '5', 'A', '8')
|
| 307 |
|
| 308 | |
| 309 | * 2 plane YCbCr
|
| 310 | * index 0 = Y plane, [7:0] Y
|
| 311 | * index 1 = Cr:Cb plane, [15:0] Cr:Cb little endian
|
| 312 | * or
|
| 313 | * index 1 = Cb:Cr plane, [15:0] Cb:Cr little endian
|
| 314 |
|
| 315 | #define DRM_FORMAT_NV12 fourcc_code('N', 'V', '1', '2')
|
| 316 | #define DRM_FORMAT_NV21 fourcc_code('N', 'V', '2', '1')
|
| 317 | #define DRM_FORMAT_NV16 fourcc_code('N', 'V', '1', '6')
|
| 318 | #define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1')
|
| 319 | #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4')
|
| 320 | #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2')
|
| 321 | |
| 322 | * 2 plane YCbCr
|
| 323 | * index 0 = Y plane, [39:0] Y3:Y2:Y1:Y0 little endian
|
| 324 | * index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
|
| 325 |
|
| 326 | #define DRM_FORMAT_NV15 fourcc_code('N', 'V', '1', '5')
|
| 327 | #define DRM_FORMAT_NV20 fourcc_code('N', 'V', '2', '0')
|
| 328 | #define DRM_FORMAT_NV30 fourcc_code('N', 'V', '3', '0')
|
| 329 |
|
| 330 | |
| 331 | * 2 plane YCbCr MSB aligned
|
| 332 | * index 0 = Y plane, [15:0] Y:x [10:6] little endian
|
| 333 | * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
|
| 334 |
|
| 335 | #define DRM_FORMAT_P210 fourcc_code('P', '2', '1', '0')
|
| 336 |
|
| 337 | |
| 338 | * 2 plane YCbCr MSB aligned
|
| 339 | * index 0 = Y plane, [15:0] Y:x [10:6] little endian
|
| 340 | * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
|
| 341 |
|
| 342 | #define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0')
|
| 343 |
|
| 344 | |
| 345 | * 2 plane YCbCr MSB aligned
|
| 346 | * index 0 = Y plane, [15:0] Y:x [12:4] little endian
|
| 347 | * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
|
| 348 |
|
| 349 | #define DRM_FORMAT_P012 fourcc_code('P', '0', '1', '2')
|
| 350 |
|
| 351 | |
| 352 | * 2 plane YCbCr MSB aligned
|
| 353 | * index 0 = Y plane, [15:0] Y little endian
|
| 354 | * index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
|
| 355 |
|
| 356 | #define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6')
|
| 357 |
|
| 358 | |
| 359 | * 3 10 bit components and 2 padding bits packed into 4 bytes.
|
| 360 | * index 0 = Y plane, [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian
|
| 361 | * index 1 = Cr:Cb plane, [63:0] x:Cr2:Cb2:Cr1:x:Cb1:Cr0:Cb0 [2:10:10:10:2:10:10:10] little endian
|
| 362 |
|
| 363 | #define DRM_FORMAT_P030 fourcc_code('P', '0', '3', '0')
|
| 364 |
|
| 365 | |
| 366 | * 2 plane YCbCr422.
|
| 367 | * 3 10 bit components and 2 padding bits packed into 4 bytes.
|
| 368 | * index 0 = Y plane, [31:0] x:Y2:Y1:Y0 2:10:10:10 little endian
|
| 369 | * index 1 = Cr:Cb plane, [63:0] x:Cr2:Cb2:Cr1:x:Cb1:Cr0:Cb0 [2:10:10:10:2:10:10:10] little endian
|
| 370 |
|
| 371 | #define DRM_FORMAT_P230 fourcc_code('P', '2', '3', '0')
|
| 372 |
|
| 373 | |
| 374 | * 16 bits per component, but only 10 bits are used and 6 bits are padded
|
| 375 | * index 0: Y plane, [15:0] Y:x [10:6] little endian
|
| 376 | * index 1: Cb plane, [15:0] Cb:x [10:6] little endian
|
| 377 | * index 2: Cr plane, [15:0] Cr:x [10:6] little endian
|
| 378 |
|
| 379 | #define DRM_FORMAT_Q410 fourcc_code('Q', '4', '1', '0')
|
| 380 |
|
| 381 | |
| 382 | * 16 bits per component, but only 10 bits are used and 6 bits are padded
|
| 383 | * index 0: Y plane, [15:0] Y:x [10:6] little endian
|
| 384 | * index 1: Cr plane, [15:0] Cr:x [10:6] little endian
|
| 385 | * index 2: Cb plane, [15:0] Cb:x [10:6] little endian
|
| 386 |
|
| 387 | #define DRM_FORMAT_Q401 fourcc_code('Q', '4', '0', '1')
|
| 388 |
|
| 389 | |
| 390 | * 3 plane non-subsampled (444) YCbCr LSB aligned
|
| 391 | * 10 bpc, 30 bits per sample image data in a single contiguous buffer.
|
| 392 | * index 0: Y plane, [31:0] x:Y2:Y1:Y0 [2:10:10:10] little endian
|
| 393 | * index 1: Cb plane, [31:0] x:Cb2:Cb1:Cb0 [2:10:10:10] little endian
|
| 394 | * index 2: Cr plane, [31:0] x:Cr2:Cr1:Cr0 [2:10:10:10] little endian
|
| 395 |
|
| 396 | #define DRM_FORMAT_T430 fourcc_code('T', '4', '3', '0')
|
| 397 |
|
| 398 | |
| 399 | * 3 plane YCbCr LSB aligned
|
| 400 | * In order to use these formats in a similar fashion to MSB aligned ones
|
| 401 | * implementation can multiply the values by 2^6=64. For that reason the padding
|
| 402 | * must only contain zeros.
|
| 403 | * index 0 = Y plane, [15:0] z:Y [6:10] little endian
|
| 404 | * index 1 = Cb plane, [15:0] z:Cb [6:10] little endian
|
| 405 | * index 2 = Cr plane, [15:0] z:Cr [6:10] little endian
|
| 406 |
|
| 407 | #define DRM_FORMAT_S010 fourcc_code('S', '0', '1', '0')
|
| 408 | #define DRM_FORMAT_S210 fourcc_code('S', '2', '1', '0')
|
| 409 | #define DRM_FORMAT_S410 fourcc_code('S', '4', '1', '0')
|
| 410 |
|
| 411 | |
| 412 | * 3 plane YCbCr LSB aligned
|
| 413 | * In order to use these formats in a similar fashion to MSB aligned ones
|
| 414 | * implementation can multiply the values by 2^4=16. For that reason the padding
|
| 415 | * must only contain zeros.
|
| 416 | * index 0 = Y plane, [15:0] z:Y [4:12] little endian
|
| 417 | * index 1 = Cb plane, [15:0] z:Cb [4:12] little endian
|
| 418 | * index 2 = Cr plane, [15:0] z:Cr [4:12] little endian
|
| 419 |
|
| 420 | #define DRM_FORMAT_S012 fourcc_code('S', '0', '1', '2')
|
| 421 | #define DRM_FORMAT_S212 fourcc_code('S', '2', '1', '2')
|
| 422 | #define DRM_FORMAT_S412 fourcc_code('S', '4', '1', '2')
|
| 423 |
|
| 424 | |
| 425 | * 3 plane YCbCr
|
| 426 | * index 0 = Y plane, [15:0] Y little endian
|
| 427 | * index 1 = Cb plane, [15:0] Cb little endian
|
| 428 | * index 2 = Cr plane, [15:0] Cr little endian
|
| 429 |
|
| 430 | #define DRM_FORMAT_S016 fourcc_code('S', '0', '1', '6')
|
| 431 | #define DRM_FORMAT_S216 fourcc_code('S', '2', '1', '6')
|
| 432 | #define DRM_FORMAT_S416 fourcc_code('S', '4', '1', '6')
|
| 433 |
|
| 434 | |
| 435 | * 3 plane YCbCr
|
| 436 | * index 0: Y plane, [7:0] Y
|
| 437 | * index 1: Cb plane, [7:0] Cb
|
| 438 | * index 2: Cr plane, [7:0] Cr
|
| 439 | * or
|
| 440 | * index 1: Cr plane, [7:0] Cr
|
| 441 | * index 2: Cb plane, [7:0] Cb
|
| 442 |
|
| 443 | #define DRM_FORMAT_YUV410 fourcc_code('Y', 'U', 'V', '9')
|
| 444 | #define DRM_FORMAT_YVU410 fourcc_code('Y', 'V', 'U', '9')
|
| 445 | #define DRM_FORMAT_YUV411 fourcc_code('Y', 'U', '1', '1')
|
| 446 | #define DRM_FORMAT_YVU411 fourcc_code('Y', 'V', '1', '1')
|
| 447 | #define DRM_FORMAT_YUV420 fourcc_code('Y', 'U', '1', '2')
|
| 448 | #define DRM_FORMAT_YVU420 fourcc_code('Y', 'V', '1', '2')
|
| 449 | #define DRM_FORMAT_YUV422 fourcc_code('Y', 'U', '1', '6')
|
| 450 | #define DRM_FORMAT_YVU422 fourcc_code('Y', 'V', '1', '6')
|
| 451 | #define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4')
|
| 452 | #define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4')
|
| 453 |
|
| 454 | |
| 455 | * Y-only (greyscale) formats
|
| 456 | *
|
| 457 | * The Y-only formats are handled similarly to the YCbCr formats in the display
|
| 458 | * pipeline, with the Cb and Cr implicitly neutral (0.0 in nominal values). This
|
| 459 | * also means that COLOR_RANGE property applies to the Y-only formats.
|
| 460 |
|
| 461 |
|
| 462 | #define DRM_FORMAT_Y8 fourcc_code('G', 'R', 'E', 'Y')
|
| 463 | #define DRM_FORMAT_XYYY2101010 fourcc_code('Y', 'P', 'A', '4')
|
| 464 |
|
| 465 | |
| 466 | * Format Modifiers:
|
| 467 | *
|
| 468 | * Format modifiers describe, typically, a re-ordering or modification
|
| 469 | * of the data in a plane of an FB. This can be used to express tiled/
|
| 470 | * swizzled formats, or compression, or a combination of the two.
|
| 471 | *
|
| 472 | * The upper 8 bits of the format modifier are a vendor-id as assigned
|
| 473 | * below. The lower 56 bits are assigned as vendor sees fit.
|
| 474 |
|
| 475 |
|
| 476 |
|
| 477 | #define DRM_FORMAT_MOD_VENDOR_NONE 0
|
| 478 | #define DRM_FORMAT_MOD_VENDOR_INTEL 0x01
|
| 479 | #define DRM_FORMAT_MOD_VENDOR_AMD 0x02
|
| 480 | #define DRM_FORMAT_MOD_VENDOR_NVIDIA 0x03
|
| 481 | #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
|
| 482 | #define DRM_FORMAT_MOD_VENDOR_QCOM 0x05
|
| 483 | #define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
|
| 484 | #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
|
| 485 | #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
|
| 486 | #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
|
| 487 | #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
|
| 488 | #define DRM_FORMAT_MOD_VENDOR_MTK 0x0b
|
| 489 | #define DRM_FORMAT_MOD_VENDOR_APPLE 0x0c
|
| 490 |
|
| 491 |
|
| 492 |
|
| 493 | #define DRM_FORMAT_RESERVED ((1ULL << 56) - 1)
|
| 494 |
|
| 495 | #define fourcc_mod_get_vendor(modifier) \
|
| 496 | (((modifier) >> 56) & 0xff)
|
| 497 |
|
| 498 | #define fourcc_mod_is_vendor(modifier, vendor) \
|
| 499 | (fourcc_mod_get_vendor(modifier) == DRM_FORMAT_MOD_VENDOR_## vendor)
|
| 500 |
|
| 501 | #define fourcc_mod_code(vendor, val) \
|
| 502 | ((((__u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | ((val) & 0x00ffffffffffffffULL))
|
| 503 |
|
| 504 | |
| 505 | * Format Modifier tokens:
|
| 506 | *
|
| 507 | * When adding a new token please document the layout with a code comment,
|
| 508 | * similar to the fourcc codes above. drm_fourcc.h is considered the
|
| 509 | * authoritative source for all of these.
|
| 510 | *
|
| 511 | * Generic modifier names:
|
| 512 | *
|
| 513 | * DRM_FORMAT_MOD_GENERIC_* definitions are used to provide vendor-neutral names
|
| 514 | * for layouts which are common across multiple vendors. To preserve
|
| 515 | * compatibility, in cases where a vendor-specific definition already exists and
|
| 516 | * a generic name for it is desired, the common name is a purely symbolic alias
|
| 517 | * and must use the same numerical value as the original definition.
|
| 518 | *
|
| 519 | * Note that generic names should only be used for modifiers which describe
|
| 520 | * generic layouts (such as pixel re-ordering), which may have
|
| 521 | * independently-developed support across multiple vendors.
|
| 522 | *
|
| 523 | * In future cases where a generic layout is identified before merging with a
|
| 524 | * vendor-specific modifier, a new 'GENERIC' vendor or modifier using vendor
|
| 525 | * 'NONE' could be considered. This should only be for obvious, exceptional
|
| 526 | * cases to avoid polluting the 'GENERIC' namespace with modifiers which only
|
| 527 | * apply to a single vendor.
|
| 528 | *
|
| 529 | * Generic names should not be used for cases where multiple hardware vendors
|
| 530 | * have implementations of the same standardised compression scheme (such as
|
| 531 | * AFBC). In those cases, all implementations should use the same format
|
| 532 | * modifier(s), reflecting the vendor of the standard.
|
| 533 |
|
| 534 |
|
| 535 | #define DRM_FORMAT_MOD_GENERIC_16_16_TILE DRM_FORMAT_MOD_SAMSUNG_16_16_TILE
|
| 536 |
|
| 537 | |
| 538 | * Invalid Modifier
|
| 539 | *
|
| 540 | * This modifier can be used as a sentinel to terminate the format modifiers
|
| 541 | * list, or to initialize a variable with an invalid modifier. It might also be
|
| 542 | * used to report an error back to userspace for certain APIs.
|
| 543 |
|
| 544 | #define DRM_FORMAT_MOD_INVALID fourcc_mod_code(NONE, DRM_FORMAT_RESERVED)
|
| 545 |
|
| 546 | |
| 547 | * Linear Layout
|
| 548 | *
|
| 549 | * Just plain linear layout. Note that this is different from no specifying any
|
| 550 | * modifier (e.g. not setting DRM_MODE_FB_MODIFIERS in the DRM_ADDFB2 ioctl),
|
| 551 | * which tells the driver to also take driver-internal information into account
|
| 552 | * and so might actually result in a tiled framebuffer.
|
| 553 |
|
| 554 | #define DRM_FORMAT_MOD_LINEAR fourcc_mod_code(NONE, 0)
|
| 555 |
|
| 556 | |
| 557 | * Deprecated: use DRM_FORMAT_MOD_LINEAR instead
|
| 558 | *
|
| 559 | * The "none" format modifier doesn't actually mean that the modifier is
|
| 560 | * implicit, instead it means that the layout is linear. Whether modifiers are
|
| 561 | * used is out-of-band information carried in an API-specific way (e.g. in a
|
| 562 | * flag for drm_mode_fb_cmd2).
|
| 563 |
|
| 564 | #define DRM_FORMAT_MOD_NONE 0
|
| 565 |
|
| 566 |
|
| 567 |
|
| 568 | |
| 569 | * Intel X-tiling layout
|
| 570 | *
|
| 571 | * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb)
|
| 572 | * in row-major layout. Within the tile bytes are laid out row-major, with
|
| 573 | * a platform-dependent stride. On top of that the memory can apply
|
| 574 | * platform-depending swizzling of some higher address bits into bit6.
|
| 575 | *
|
| 576 | * Note that this layout is only accurate on intel gen 8+ or valleyview chipsets.
|
| 577 | * On earlier platforms the is highly platforms specific and not useful for
|
| 578 | * cross-driver sharing. It exists since on a given platform it does uniquely
|
| 579 | * identify the layout in a simple way for i915-specific userspace, which
|
| 580 | * facilitated conversion of userspace to modifiers. Additionally the exact
|
| 581 | * format on some really old platforms is not known.
|
| 582 |
|
| 583 | #define I915_FORMAT_MOD_X_TILED fourcc_mod_code(INTEL, 1)
|
| 584 |
|
| 585 | |
| 586 | * Intel Y-tiling layout
|
| 587 | *
|
| 588 | * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles 2Kb)
|
| 589 | * in row-major layout. Within the tile bytes are laid out in OWORD (16 bytes)
|
| 590 | * chunks column-major, with a platform-dependent height. On top of that the
|
| 591 | * memory can apply platform-depending swizzling of some higher address bits
|
| 592 | * into bit6.
|
| 593 | *
|
| 594 | * Note that this layout is only accurate on intel gen 8+ or valleyview chipsets.
|
| 595 | * On earlier platforms the is highly platforms specific and not useful for
|
| 596 | * cross-driver sharing. It exists since on a given platform it does uniquely
|
| 597 | * identify the layout in a simple way for i915-specific userspace, which
|
| 598 | * facilitated conversion of userspace to modifiers. Additionally the exact
|
| 599 | * format on some really old platforms is not known.
|
| 600 |
|
| 601 | #define I915_FORMAT_MOD_Y_TILED fourcc_mod_code(INTEL, 2)
|
| 602 |
|
| 603 | |
| 604 | * Intel Yf-tiling layout
|
| 605 | *
|
| 606 | * This is a tiled layout using 4Kb tiles in row-major layout.
|
| 607 | * Within the tile pixels are laid out in 16 256 byte units / sub-tiles which
|
| 608 | * are arranged in four groups (two wide, two high) with column-major layout.
|
| 609 | * Each group therefore consists out of four 256 byte units, which are also laid
|
| 610 | * out as 2x2 column-major.
|
| 611 | * 256 byte units are made out of four 64 byte blocks of pixels, producing
|
| 612 | * either a square block or a 2:1 unit.
|
| 613 | * 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the width
|
| 614 | * in pixel depends on the pixel depth.
|
| 615 |
|
| 616 | #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
|
| 617 |
|
| 618 | |
| 619 | * Intel color control surface (CCS) for render compression
|
| 620 | *
|
| 621 | * The framebuffer format must be one of the 8:8:8:8 RGB formats.
|
| 622 | * The main surface will be plane index 0 and must be Y/Yf-tiled,
|
| 623 | * the CCS will be plane index 1.
|
| 624 | *
|
| 625 | * Each CCS tile matches a 1024x512 pixel area of the main surface.
|
| 626 | * To match certain aspects of the 3D hardware the CCS is
|
| 627 | * considered to be made up of normal 128Bx32 Y tiles, Thus
|
| 628 | * the CCS pitch must be specified in multiples of 128 bytes.
|
| 629 | *
|
| 630 | * In reality the CCS tile appears to be a 64Bx64 Y tile, composed
|
| 631 | * of QWORD (8 bytes) chunks instead of OWORD (16 bytes) chunks.
|
| 632 | * But that fact is not relevant unless the memory is accessed
|
| 633 | * directly.
|
| 634 |
|
| 635 | #define I915_FORMAT_MOD_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
|
| 636 | #define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
|
| 637 |
|
| 638 | |
| 639 | * Intel color control surfaces (CCS) for Gen-12 render compression.
|
| 640 | *
|
| 641 | * The main surface is Y-tiled and at plane index 0, the CCS is linear and
|
| 642 | * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
|
| 643 | * main surface. In other words, 4 bits in CCS map to a main surface cache
|
| 644 | * line pair. The main surface pitch is required to be a multiple of four
|
| 645 | * Y-tile widths.
|
| 646 |
|
| 647 | #define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL, 6)
|
| 648 |
|
| 649 | |
| 650 | * Intel color control surfaces (CCS) for Gen-12 media compression
|
| 651 | *
|
| 652 | * The main surface is Y-tiled and at plane index 0, the CCS is linear and
|
| 653 | * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
|
| 654 | * main surface. In other words, 4 bits in CCS map to a main surface cache
|
| 655 | * line pair. The main surface pitch is required to be a multiple of four
|
| 656 | * Y-tile widths. For semi-planar formats like NV12, CCS planes follow the
|
| 657 | * Y and UV planes i.e., planes 0 and 1 are used for Y and UV surfaces,
|
| 658 | * planes 2 and 3 for the respective CCS.
|
| 659 |
|
| 660 | #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
|
| 661 |
|
| 662 | |
| 663 | * Intel Color Control Surface with Clear Color (CCS) for Gen-12 render
|
| 664 | * compression.
|
| 665 | *
|
| 666 | * The main surface is Y-tiled and is at plane index 0 whereas CCS is linear
|
| 667 | * and at index 1. The clear color is stored at index 2, and the pitch should
|
| 668 | * be 64 bytes aligned. The clear color structure is 256 bits. The first 128 bits
|
| 669 | * represents Raw Clear Color Red, Green, Blue and Alpha color each represented
|
| 670 | * by 32 bits. The raw clear color is consumed by the 3d engine and generates
|
| 671 | * the converted clear color of size 64 bits. The first 32 bits store the Lower
|
| 672 | * Converted Clear Color value and the next 32 bits store the Higher Converted
|
| 673 | * Clear Color value when applicable. The Converted Clear Color values are
|
| 674 | * consumed by the DE. The last 64 bits are used to store Color Discard Enable
|
| 675 | * and Depth Clear Value Valid which are ignored by the DE. A CCS cache line
|
| 676 | * corresponds to an area of 4x1 tiles in the main surface. The main surface
|
| 677 | * pitch is required to be a multiple of 4 tile widths.
|
| 678 |
|
| 679 | #define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
|
| 680 |
|
| 681 | |
| 682 | * Intel Tile 4 layout
|
| 683 | *
|
| 684 | * This is a tiled layout using 4KB tiles in a row-major layout. It has the same
|
| 685 | * shape as Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x 4). It
|
| 686 | * only differs from Tile Y at the 256B granularity in between. At this
|
| 687 | * granularity, Tile Y has a shape of 16B x 32 rows, but this tiling has a shape
|
| 688 | * of 64B x 8 rows.
|
| 689 |
|
| 690 | #define I915_FORMAT_MOD_4_TILED fourcc_mod_code(INTEL, 9)
|
| 691 |
|
| 692 | |
| 693 | * Intel color control surfaces (CCS) for DG2 render compression.
|
| 694 | *
|
| 695 | * The main surface is Tile 4 and at plane index 0. The CCS data is stored
|
| 696 | * outside of the GEM object in a reserved memory area dedicated for the
|
| 697 | * storage of the CCS data for all RC/RC_CC/MC compressible GEM objects. The
|
| 698 | * main surface pitch is required to be a multiple of four Tile 4 widths.
|
| 699 |
|
| 700 | #define I915_FORMAT_MOD_4_TILED_DG2_RC_CCS fourcc_mod_code(INTEL, 10)
|
| 701 |
|
| 702 | |
| 703 | * Intel color control surfaces (CCS) for DG2 media compression.
|
| 704 | *
|
| 705 | * The main surface is Tile 4 and at plane index 0. For semi-planar formats
|
| 706 | * like NV12, the Y and UV planes are Tile 4 and are located at plane indices
|
| 707 | * 0 and 1, respectively. The CCS for all planes are stored outside of the
|
| 708 | * GEM object in a reserved memory area dedicated for the storage of the
|
| 709 | * CCS data for all RC/RC_CC/MC compressible GEM objects. The main surface
|
| 710 | * pitch is required to be a multiple of four Tile 4 widths.
|
| 711 |
|
| 712 | #define I915_FORMAT_MOD_4_TILED_DG2_MC_CCS fourcc_mod_code(INTEL, 11)
|
| 713 |
|
| 714 | |
| 715 | * Intel Color Control Surface with Clear Color (CCS) for DG2 render compression.
|
| 716 | *
|
| 717 | * The main surface is Tile 4 and at plane index 0. The CCS data is stored
|
| 718 | * outside of the GEM object in a reserved memory area dedicated for the
|
| 719 | * storage of the CCS data for all RC/RC_CC/MC compressible GEM objects. The
|
| 720 | * main surface pitch is required to be a multiple of four Tile 4 widths. The
|
| 721 | * clear color is stored at plane index 1 and the pitch should be 64 bytes
|
| 722 | * aligned. The format of the 256 bits of clear color data matches the one used
|
| 723 | * for the I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC modifier, see its description
|
| 724 | * for details.
|
| 725 |
|
| 726 | #define I915_FORMAT_MOD_4_TILED_DG2_RC_CCS_CC fourcc_mod_code(INTEL, 12)
|
| 727 |
|
| 728 | |
| 729 | * Intel Color Control Surfaces (CCS) for display ver. 14 render compression.
|
| 730 | *
|
| 731 | * The main surface is tile4 and at plane index 0, the CCS is linear and
|
| 732 | * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
|
| 733 | * main surface. In other words, 4 bits in CCS map to a main surface cache
|
| 734 | * line pair. The main surface pitch is required to be a multiple of four
|
| 735 | * tile4 widths.
|
| 736 |
|
| 737 | #define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS fourcc_mod_code(INTEL, 13)
|
| 738 |
|
| 739 | |
| 740 | * Intel Color Control Surfaces (CCS) for display ver. 14 media compression
|
| 741 | *
|
| 742 | * The main surface is tile4 and at plane index 0, the CCS is linear and
|
| 743 | * at index 1. A 64B CCS cache line corresponds to an area of 4x1 tiles in
|
| 744 | * main surface. In other words, 4 bits in CCS map to a main surface cache
|
| 745 | * line pair. The main surface pitch is required to be a multiple of four
|
| 746 | * tile4 widths. For semi-planar formats like NV12, CCS planes follow the
|
| 747 | * Y and UV planes i.e., planes 0 and 1 are used for Y and UV surfaces,
|
| 748 | * planes 2 and 3 for the respective CCS.
|
| 749 |
|
| 750 | #define I915_FORMAT_MOD_4_TILED_MTL_MC_CCS fourcc_mod_code(INTEL, 14)
|
| 751 |
|
| 752 | |
| 753 | * Intel Color Control Surface with Clear Color (CCS) for display ver. 14 render
|
| 754 | * compression.
|
| 755 | *
|
| 756 | * The main surface is tile4 and is at plane index 0 whereas CCS is linear
|
| 757 | * and at index 1. The clear color is stored at index 2, and the pitch should
|
| 758 | * be ignored. The clear color structure is 256 bits. The first 128 bits
|
| 759 | * represents Raw Clear Color Red, Green, Blue and Alpha color each represented
|
| 760 | * by 32 bits. The raw clear color is consumed by the 3d engine and generates
|
| 761 | * the converted clear color of size 64 bits. The first 32 bits store the Lower
|
| 762 | * Converted Clear Color value and the next 32 bits store the Higher Converted
|
| 763 | * Clear Color value when applicable. The Converted Clear Color values are
|
| 764 | * consumed by the DE. The last 64 bits are used to store Color Discard Enable
|
| 765 | * and Depth Clear Value Valid which are ignored by the DE. A CCS cache line
|
| 766 | * corresponds to an area of 4x1 tiles in the main surface. The main surface
|
| 767 | * pitch is required to be a multiple of 4 tile widths.
|
| 768 |
|
| 769 | #define I915_FORMAT_MOD_4_TILED_MTL_RC_CCS_CC fourcc_mod_code(INTEL, 15)
|
| 770 |
|
| 771 | |
| 772 | * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression
|
| 773 | * on integrated graphics
|
| 774 | *
|
| 775 | * The main surface is Tile 4 and at plane index 0. For semi-planar formats
|
| 776 | * like NV12, the Y and UV planes are Tile 4 and are located at plane indices
|
| 777 | * 0 and 1, respectively. The CCS for all planes are stored outside of the
|
| 778 | * GEM object in a reserved memory area dedicated for the storage of the
|
| 779 | * CCS data for all compressible GEM objects.
|
| 780 |
|
| 781 | #define I915_FORMAT_MOD_4_TILED_LNL_CCS fourcc_mod_code(INTEL, 16)
|
| 782 |
|
| 783 | |
| 784 | * Intel Color Control Surfaces (CCS) for graphics ver. 20 unified compression
|
| 785 | * on discrete graphics
|
| 786 | *
|
| 787 | * The main surface is Tile 4 and at plane index 0. For semi-planar formats
|
| 788 | * like NV12, the Y and UV planes are Tile 4 and are located at plane indices
|
| 789 | * 0 and 1, respectively. The CCS for all planes are stored outside of the
|
| 790 | * GEM object in a reserved memory area dedicated for the storage of the
|
| 791 | * CCS data for all compressible GEM objects. The GEM object must be stored in
|
| 792 | * contiguous memory with a size aligned to 64KB
|
| 793 |
|
| 794 | #define I915_FORMAT_MOD_4_TILED_BMG_CCS fourcc_mod_code(INTEL, 17)
|
| 795 |
|
| 796 | |
| 797 | * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
|
| 798 | *
|
| 799 | * Macroblocks are laid in a Z-shape, and each pixel data is following the
|
| 800 | * standard NV12 style.
|
| 801 | * As for NV12, an image is the result of two frame buffers: one for Y,
|
| 802 | * one for the interleaved Cb/Cr components (1/2 the height of the Y buffer).
|
| 803 | * Alignment requirements are (for each buffer):
|
| 804 | * - multiple of 128 pixels for the width
|
| 805 | * - multiple of 32 pixels for the height
|
| 806 | *
|
| 807 | * For more information: see https://linuxtv.org/downloads/v4l-dvb-apis/re32.html
|
| 808 |
|
| 809 | #define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
|
| 810 |
|
| 811 | |
| 812 | * Tiled, 16 (pixels) x 16 (lines) - sized macroblocks
|
| 813 | *
|
| 814 | * This is a simple tiled layout using tiles of 16x16 pixels in a row-major
|
| 815 | * layout. For YCbCr formats Cb/Cr components are taken in such a way that
|
| 816 | * they correspond to their 16x16 luma block.
|
| 817 |
|
| 818 | #define DRM_FORMAT_MOD_SAMSUNG_16_16_TILE fourcc_mod_code(SAMSUNG, 2)
|
| 819 |
|
| 820 | |
| 821 | * Qualcomm Compressed Format
|
| 822 | *
|
| 823 | * Refers to a compressed variant of the base format that is compressed.
|
| 824 | * Implementation may be platform and base-format specific.
|
| 825 | *
|
| 826 | * Each macrotile consists of m x n (mostly 4 x 4) tiles.
|
| 827 | * Pixel data pitch/stride is aligned with macrotile width.
|
| 828 | * Pixel data height is aligned with macrotile height.
|
| 829 | * Entire pixel data buffer is aligned with 4k(bytes).
|
| 830 |
|
| 831 | #define DRM_FORMAT_MOD_QCOM_COMPRESSED fourcc_mod_code(QCOM, 1)
|
| 832 |
|
| 833 | |
| 834 | * Qualcomm Tiled Format
|
| 835 | *
|
| 836 | * Similar to DRM_FORMAT_MOD_QCOM_COMPRESSED but not compressed.
|
| 837 | * Implementation may be platform and base-format specific.
|
| 838 | *
|
| 839 | * Each macrotile consists of m x n (mostly 4 x 4) tiles.
|
| 840 | * Pixel data pitch/stride is aligned with macrotile width.
|
| 841 | * Pixel data height is aligned with macrotile height.
|
| 842 | * Entire pixel data buffer is aligned with 4k(bytes).
|
| 843 |
|
| 844 | #define DRM_FORMAT_MOD_QCOM_TILED3 fourcc_mod_code(QCOM, 3)
|
| 845 |
|
| 846 | |
| 847 | * Qualcomm Alternate Tiled Format
|
| 848 | *
|
| 849 | * Alternate tiled format typically only used within GMEM.
|
| 850 | * Implementation may be platform and base-format specific.
|
| 851 |
|
| 852 | #define DRM_FORMAT_MOD_QCOM_TILED2 fourcc_mod_code(QCOM, 2)
|
| 853 |
|
| 854 |
|
| 855 |
|
| 856 |
|
| 857 | |
| 858 | * Vivante 4x4 tiling layout
|
| 859 | *
|
| 860 | * This is a simple tiled layout using tiles of 4x4 pixels in a row-major
|
| 861 | * layout.
|
| 862 |
|
| 863 | #define DRM_FORMAT_MOD_VIVANTE_TILED fourcc_mod_code(VIVANTE, 1)
|
| 864 |
|
| 865 | |
| 866 | * Vivante 64x64 super-tiling layout
|
| 867 | *
|
| 868 | * This is a tiled layout using 64x64 pixel super-tiles, where each super-tile
|
| 869 | * contains 8x4 groups of 2x4 tiles of 4x4 pixels (like above) each, all in row-
|
| 870 | * major layout.
|
| 871 | *
|
| 872 | * For more information: see
|
| 873 | * https://github.com/etnaviv/etna_viv/blob/master/doc/hardware.md#texture-tiling
|
| 874 |
|
| 875 | #define DRM_FORMAT_MOD_VIVANTE_SUPER_TILED fourcc_mod_code(VIVANTE, 2)
|
| 876 |
|
| 877 | |
| 878 | * Vivante 4x4 tiling layout for dual-pipe
|
| 879 | *
|
| 880 | * Same as the 4x4 tiling layout, except every second 4x4 pixel tile starts at a
|
| 881 | * different base address. Offsets from the base addresses are therefore halved
|
| 882 | * compared to the non-split tiled layout.
|
| 883 |
|
| 884 | #define DRM_FORMAT_MOD_VIVANTE_SPLIT_TILED fourcc_mod_code(VIVANTE, 3)
|
| 885 |
|
| 886 | |
| 887 | * Vivante 64x64 super-tiling layout for dual-pipe
|
| 888 | *
|
| 889 | * Same as the 64x64 super-tiling layout, except every second 4x4 pixel tile
|
| 890 | * starts at a different base address. Offsets from the base addresses are
|
| 891 | * therefore halved compared to the non-split super-tiled layout.
|
| 892 |
|
| 893 | #define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE, 4)
|
| 894 |
|
| 895 | |
| 896 | * Vivante TS (tile-status) buffer modifiers. They can be combined with all of
|
| 897 | * the color buffer tiling modifiers defined above. When TS is present it's a
|
| 898 | * separate buffer containing the clear/compression status of each tile. The
|
| 899 | * modifiers are defined as VIVANTE_MOD_TS_c_s, where c is the color buffer
|
| 900 | * tile size in bytes covered by one entry in the status buffer and s is the
|
| 901 | * number of status bits per entry.
|
| 902 | * We reserve the top 8 bits of the Vivante modifier space for tile status
|
| 903 | * clear/compression modifiers, as future cores might add some more TS layout
|
| 904 | * variations.
|
| 905 |
|
| 906 | #define VIVANTE_MOD_TS_64_4 (1ULL << 48)
|
| 907 | #define VIVANTE_MOD_TS_64_2 (2ULL << 48)
|
| 908 | #define VIVANTE_MOD_TS_128_4 (3ULL << 48)
|
| 909 | #define VIVANTE_MOD_TS_256_4 (4ULL << 48)
|
| 910 | #define VIVANTE_MOD_TS_MASK (0xfULL << 48)
|
| 911 |
|
| 912 | |
| 913 | * Vivante compression modifiers. Those depend on a TS modifier being present
|
| 914 | * as the TS bits get reinterpreted as compression tags instead of simple
|
| 915 | * clear markers when compression is enabled.
|
| 916 |
|
| 917 | #define VIVANTE_MOD_COMP_DEC400 (1ULL << 52)
|
| 918 | #define VIVANTE_MOD_COMP_MASK (0xfULL << 52)
|
| 919 |
|
| 920 |
|
| 921 | #define VIVANTE_MOD_EXT_MASK (VIVANTE_MOD_TS_MASK | \
|
| 922 | VIVANTE_MOD_COMP_MASK)
|
| 923 |
|
| 924 |
|
| 925 |
|
| 926 | |
| 927 | * Tegra Tiled Layout, used by Tegra 2, 3 and 4.
|
| 928 | *
|
| 929 | * Pixels are arranged in simple tiles of 16 x 16 bytes.
|
| 930 |
|
| 931 | #define DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED fourcc_mod_code(NVIDIA, 1)
|
| 932 |
|
| 933 | |
| 934 | * Generalized Block Linear layout, used by desktop GPUs starting with NV50/G80,
|
| 935 | * and Tegra GPUs starting with Tegra K1.
|
| 936 | *
|
| 937 | * Pixels are arranged in Groups of Bytes (GOBs). GOB size and layout varies
|
| 938 | * based on the architecture generation. GOBs themselves are then arranged in
|
| 939 | * 3D blocks, with the block dimensions (in terms of GOBs) always being a power
|
| 940 | * of two, and hence expressible as their log2 equivalent (E.g., "2" represents
|
| 941 | * a block depth or height of "4").
|
| 942 | *
|
| 943 | * Chapter 20 "Pixel Memory Formats" of the Tegra X1 TRM describes this format
|
| 944 | * in full detail.
|
| 945 | *
|
| 946 | * Macro
|
| 947 | * Bits Param Description
|
| 948 | * ---- ----- -----------------------------------------------------------------
|
| 949 | *
|
| 950 | * 3:0 h log2(height) of each block, in GOBs. Placed here for
|
| 951 | * compatibility with the existing
|
| 952 | * DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()-based modifiers.
|
| 953 | *
|
| 954 | * 4:4 - Must be 1, to indicate block-linear layout. Necessary for
|
| 955 | * compatibility with the existing
|
| 956 | * DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()-based modifiers.
|
| 957 | *
|
| 958 | * 8:5 - Reserved (To support 3D-surfaces with variable log2(depth) block
|
| 959 | * size). Must be zero.
|
| 960 | *
|
| 961 | * Note there is no log2(width) parameter. Some portions of the
|
| 962 | * hardware support a block width of two gobs, but it is impractical
|
| 963 | * to use due to lack of support elsewhere, and has no known
|
| 964 | * benefits.
|
| 965 | *
|
| 966 | * 11:9 - Reserved (To support 2D-array textures with variable array stride
|
| 967 | * in blocks, specified via log2(tile width in blocks)). Must be
|
| 968 | * zero.
|
| 969 | *
|
| 970 | * 19:12 k Page Kind. This value directly maps to a field in the page
|
| 971 | * tables of all GPUs >= NV50. It affects the exact layout of bits
|
| 972 | * in memory and can be derived from the tuple
|
| 973 | *
|
| 974 | * (format, GPU model, compression type, samples per pixel)
|
| 975 | *
|
| 976 | * Where compression type is defined below. If GPU model were
|
| 977 | * implied by the format modifier, format, or memory buffer, page
|
| 978 | * kind would not need to be included in the modifier itself, but
|
| 979 | * since the modifier should define the layout of the associated
|
| 980 | * memory buffer independent from any device or other context, it
|
| 981 | * must be included here.
|
| 982 | *
|
| 983 | * 21:20 g GOB Height and Page Kind Generation. The height of a GOB changed
|
| 984 | * starting with Fermi GPUs. Additionally, the mapping between page
|
| 985 | * kind and bit layout has changed at various points.
|
| 986 | *
|
| 987 | * 0 = Gob Height 8, Fermi - Volta, Tegra K1+ Page Kind mapping
|
| 988 | * 1 = Gob Height 4, G80 - GT2XX Page Kind mapping
|
| 989 | * 2 = Gob Height 8, Turing+ Page Kind mapping
|
| 990 | * 3 = Reserved for future use.
|
| 991 | *
|
| 992 | * 22:22 s Sector layout. There is a further bit remapping step that occurs
|
| 993 | * 26:27 at an even lower level than the page kind and block linear
|
| 994 | * swizzles. This causes the bit arrangement of surfaces in memory
|
| 995 | * to differ subtly, and prevents direct sharing of surfaces between
|
| 996 | * GPUs with different layouts.
|
| 997 | *
|
| 998 | * 0 = Tegra K1 - Tegra Parker/TX2 Layout
|
| 999 | * 1 = Pre-GB20x, GB20x 32+ bpp, GB10, Tegra Xavier-Orin Layout
|
| 1000 | * 2 = GB20x(Blackwell 2)+ 8 bpp surface layout
|
| 1001 | * 3 = GB20x(Blackwell 2)+ 16 bpp surface layout
|
| 1002 | * 4 = Reserved for future use.
|
| 1003 | * 5 = Reserved for future use.
|
| 1004 | * 6 = Reserved for future use.
|
| 1005 | * 7 = Reserved for future use.
|
| 1006 | *
|
| 1007 | * 25:23 c Lossless Framebuffer Compression type.
|
| 1008 | *
|
| 1009 | * 0 = none
|
| 1010 | * 1 = ROP/3D, layout 1, exact compression format implied by Page
|
| 1011 | * Kind field
|
| 1012 | * 2 = ROP/3D, layout 2, exact compression format implied by Page
|
| 1013 | * Kind field
|
| 1014 | * 3 = CDE horizontal
|
| 1015 | * 4 = CDE vertical
|
| 1016 | * 5 = Reserved for future use
|
| 1017 | * 6 = Reserved for future use
|
| 1018 | * 7 = Reserved for future use
|
| 1019 | *
|
| 1020 | * 55:28 - Reserved for future use. Must be zero.
|
| 1021 |
|
| 1022 | #define DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(c, s, g, k, h) \
|
| 1023 | fourcc_mod_code(NVIDIA, (0x10 | \
|
| 1024 | ((h) & 0xf) | \
|
| 1025 | (((k) & 0xff) << 12) | \
|
| 1026 | (((g) & 0x3) << 20) | \
|
| 1027 | (((s) & 0x1) << 22) | \
|
| 1028 | (((s) & 0x6) << 25) | \
|
| 1029 | (((c) & 0x7) << 23)))
|
| 1030 |
|
| 1031 | |
| 1032 | * the page kind "0", which corresponds to "pitch/linear" and hence is unusable
|
| 1033 | * with block-linear layouts, is remapped within drivers to the value 0xfe,
|
| 1034 | * which corresponds to the "generic" kind used for simple single-sample
|
| 1035 | * uncompressed color formats on Fermi - Volta GPUs.
|
| 1036 |
|
| 1037 | static inline __u64
|
| 1038 | drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
|
| 1039 | {
|
| 1040 | if (!(modifier & 0x10) || (modifier & (0xff << 12)))
|
| 1041 | return modifier;
|
| 1042 | else
|
| 1043 | return modifier | (0xfe << 12);
|
| 1044 | }
|
| 1045 |
|
| 1046 | |
| 1047 | * 16Bx2 Block Linear layout, used by Tegra K1 and later
|
| 1048 | *
|
| 1049 | * Pixels are arranged in 64x8 Groups Of Bytes (GOBs). GOBs are then stacked
|
| 1050 | * vertically by a power of 2 (1 to 32 GOBs) to form a block.
|
| 1051 | *
|
| 1052 | * Within a GOB, data is ordered as 16B x 2 lines sectors laid in Z-shape.
|
| 1053 | *
|
| 1054 | * Parameter 'v' is the log2 encoding of the number of GOBs stacked vertically.
|
| 1055 | * Valid values are:
|
| 1056 | *
|
| 1057 | * 0 == ONE_GOB
|
| 1058 | * 1 == TWO_GOBS
|
| 1059 | * 2 == FOUR_GOBS
|
| 1060 | * 3 == EIGHT_GOBS
|
| 1061 | * 4 == SIXTEEN_GOBS
|
| 1062 | * 5 == THIRTYTWO_GOBS
|
| 1063 | *
|
| 1064 | * Chapter 20 "Pixel Memory Formats" of the Tegra X1 TRM describes this format
|
| 1065 | * in full detail.
|
| 1066 |
|
| 1067 | #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(v) \
|
| 1068 | DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D(0, 0, 0, 0, (v))
|
| 1069 |
|
| 1070 | #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB \
|
| 1071 | DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(0)
|
| 1072 | #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB \
|
| 1073 | DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(1)
|
| 1074 | #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB \
|
| 1075 | DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(2)
|
| 1076 | #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB \
|
| 1077 | DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(3)
|
| 1078 | #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB \
|
| 1079 | DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(4)
|
| 1080 | #define DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB \
|
| 1081 | DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(5)
|
| 1082 |
|
| 1083 | |
| 1084 | * Some Broadcom modifiers take parameters, for example the number of
|
| 1085 | * vertical lines in the image. Reserve the lower 32 bits for modifier
|
| 1086 | * type, and the next 24 bits for parameters. Top 8 bits are the
|
| 1087 | * vendor code.
|
| 1088 |
|
| 1089 | #define __fourcc_mod_broadcom_param_shift 8
|
| 1090 | #define __fourcc_mod_broadcom_param_bits 48
|
| 1091 | #define fourcc_mod_broadcom_code(val, params) \
|
| 1092 | fourcc_mod_code(BROADCOM, ((((__u64)params) << __fourcc_mod_broadcom_param_shift) | val))
|
| 1093 | #define fourcc_mod_broadcom_param(m) \
|
| 1094 | ((int)(((m) >> __fourcc_mod_broadcom_param_shift) & \
|
| 1095 | ((1ULL << __fourcc_mod_broadcom_param_bits) - 1)))
|
| 1096 | #define fourcc_mod_broadcom_mod(m) \
|
| 1097 | ((m) & ~(((1ULL << __fourcc_mod_broadcom_param_bits) - 1) << \
|
| 1098 | __fourcc_mod_broadcom_param_shift))
|
| 1099 |
|
| 1100 | |
| 1101 | * Broadcom VC4 "T" format
|
| 1102 | *
|
| 1103 | * This is the primary layout that the V3D GPU can texture from (it
|
| 1104 | * can't do linear). The T format has:
|
| 1105 | *
|
| 1106 | * - 64b utiles of pixels in a raster-order grid according to cpp. It's 4x4
|
| 1107 | * pixels at 32 bit depth.
|
| 1108 | *
|
| 1109 | * - 1k subtiles made of a 4x4 raster-order grid of 64b utiles (so usually
|
| 1110 | * 16x16 pixels).
|
| 1111 | *
|
| 1112 | * - 4k tiles made of a 2x2 grid of 1k subtiles (so usually 32x32 pixels). On
|
| 1113 | * even 4k tile rows, they're arranged as (BL, TL, TR, BR), and on odd rows
|
| 1114 | * they're (TR, BR, BL, TL), where bottom left is start of memory.
|
| 1115 | *
|
| 1116 | * - an image made of 4k tiles in rows either left-to-right (even rows of 4k
|
| 1117 | * tiles) or right-to-left (odd rows of 4k tiles).
|
| 1118 |
|
| 1119 | #define DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED fourcc_mod_code(BROADCOM, 1)
|
| 1120 |
|
| 1121 | |
| 1122 | * Broadcom SAND format
|
| 1123 | *
|
| 1124 | * This is the native format that the H.264 codec block uses. For VC4
|
| 1125 | * HVS, it is only valid for H.264 (NV12/21) and RGBA modes.
|
| 1126 | *
|
| 1127 | * The image can be considered to be split into columns, and the
|
| 1128 | * columns are placed consecutively into memory. The width of those
|
| 1129 | * columns can be either 32, 64, 128, or 256 pixels, but in practice
|
| 1130 | * only 128 pixel columns are used.
|
| 1131 | *
|
| 1132 | * The pitch between the start of each column is set to optimally
|
| 1133 | * switch between SDRAM banks. This is passed as the number of lines
|
| 1134 | * of column width in the modifier (we can't use the stride value due
|
| 1135 | * to various core checks that look at it , so you should set the
|
| 1136 | * stride to width*cpp).
|
| 1137 | *
|
| 1138 | * Note that the column height for this format modifier is the same
|
| 1139 | * for all of the planes, assuming that each column contains both Y
|
| 1140 | * and UV. Some SAND-using hardware stores UV in a separate tiled
|
| 1141 | * image from Y to reduce the column height, which is not supported
|
| 1142 | * with these modifiers.
|
| 1143 | *
|
| 1144 | * The DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT modifier is also
|
| 1145 | * supported for DRM_FORMAT_P030 where the columns remain as 128 bytes
|
| 1146 | * wide, but as this is a 10 bpp format that translates to 96 pixels.
|
| 1147 |
|
| 1148 |
|
| 1149 | #define DRM_FORMAT_MOD_BROADCOM_SAND32_COL_HEIGHT(v) \
|
| 1150 | fourcc_mod_broadcom_code(2, v)
|
| 1151 | #define DRM_FORMAT_MOD_BROADCOM_SAND64_COL_HEIGHT(v) \
|
| 1152 | fourcc_mod_broadcom_code(3, v)
|
| 1153 | #define DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT(v) \
|
| 1154 | fourcc_mod_broadcom_code(4, v)
|
| 1155 | #define DRM_FORMAT_MOD_BROADCOM_SAND256_COL_HEIGHT(v) \
|
| 1156 | fourcc_mod_broadcom_code(5, v)
|
| 1157 |
|
| 1158 | #define DRM_FORMAT_MOD_BROADCOM_SAND32 \
|
| 1159 | DRM_FORMAT_MOD_BROADCOM_SAND32_COL_HEIGHT(0)
|
| 1160 | #define DRM_FORMAT_MOD_BROADCOM_SAND64 \
|
| 1161 | DRM_FORMAT_MOD_BROADCOM_SAND64_COL_HEIGHT(0)
|
| 1162 | #define DRM_FORMAT_MOD_BROADCOM_SAND128 \
|
| 1163 | DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT(0)
|
| 1164 | #define DRM_FORMAT_MOD_BROADCOM_SAND256 \
|
| 1165 | DRM_FORMAT_MOD_BROADCOM_SAND256_COL_HEIGHT(0)
|
| 1166 |
|
| 1167 | |
| 1168 | *
|
| 1169 | * This is the common format for the current Broadcom multimedia
|
| 1170 | * blocks, including V3D 3.x and newer, newer video codecs, and
|
| 1171 | * displays.
|
| 1172 | *
|
| 1173 | * The image consists of utiles (64b blocks), UIF blocks (2x2 utiles),
|
| 1174 | * and macroblocks (4x4 UIF blocks). Those 4x4 UIF block groups are
|
| 1175 | * stored in columns, with padding between the columns to ensure that
|
| 1176 | * moving from one column to the next doesn't hit the same SDRAM page
|
| 1177 | * bank.
|
| 1178 | *
|
| 1179 | * To calculate the padding, it is assumed that each hardware block
|
| 1180 | * and the software driving it knows the platform's SDRAM page size,
|
| 1181 | * number of banks, and XOR address, and that it's identical between
|
| 1182 | * all blocks using the format. This tiling modifier will use XOR as
|
| 1183 | * necessary to reduce the padding. If a hardware block can't do XOR,
|
| 1184 | * the assumption is that a no-XOR tiling modifier will be created.
|
| 1185 |
|
| 1186 | #define DRM_FORMAT_MOD_BROADCOM_UIF fourcc_mod_code(BROADCOM, 6)
|
| 1187 |
|
| 1188 | |
| 1189 | * Arm Framebuffer Compression (AFBC) modifiers
|
| 1190 | *
|
| 1191 | * AFBC is a proprietary lossless image compression protocol and format.
|
| 1192 | * It provides fine-grained random access and minimizes the amount of data
|
| 1193 | * transferred between IP blocks.
|
| 1194 | *
|
| 1195 | * AFBC has several features which may be supported and/or used, which are
|
| 1196 | * represented using bits in the modifier. Not all combinations are valid,
|
| 1197 | * and different devices or use-cases may support different combinations.
|
| 1198 | *
|
| 1199 | * Further information on the use of AFBC modifiers can be found in
|
| 1200 | * Documentation/gpu/afbc.rst
|
| 1201 |
|
| 1202 |
|
| 1203 | |
| 1204 | * The top 4 bits (out of the 56 bits allotted for specifying vendor specific
|
| 1205 | * modifiers) denote the category for modifiers. Currently we have three
|
| 1206 | * categories of modifiers ie AFBC, MISC and AFRC. We can have a maximum of
|
| 1207 | * sixteen different categories.
|
| 1208 |
|
| 1209 | #define DRM_FORMAT_MOD_ARM_CODE(__type, __val) \
|
| 1210 | fourcc_mod_code(ARM, ((__u64)(__type) << 52) | ((__val) & 0x000fffffffffffffULL))
|
| 1211 |
|
| 1212 | #define DRM_FORMAT_MOD_ARM_TYPE_AFBC 0x00
|
| 1213 | #define DRM_FORMAT_MOD_ARM_TYPE_MISC 0x01
|
| 1214 |
|
| 1215 | #define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) \
|
| 1216 | DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AFBC, __afbc_mode)
|
| 1217 |
|
| 1218 | |
| 1219 | * AFBC superblock size
|
| 1220 | *
|
| 1221 | * Indicates the superblock size(s) used for the AFBC buffer. The buffer
|
| 1222 | * size (in pixels) must be aligned to a multiple of the superblock size.
|
| 1223 | * Four lowest significant bits(LSBs) are reserved for block size.
|
| 1224 | *
|
| 1225 | * Where one superblock size is specified, it applies to all planes of the
|
| 1226 | * buffer (e.g. 16x16, 32x8). When multiple superblock sizes are specified,
|
| 1227 | * the first applies to the Luma plane and the second applies to the Chroma
|
| 1228 | * plane(s). e.g. (32x8_64x4 means 32x8 Luma, with 64x4 Chroma).
|
| 1229 | * Multiple superblock sizes are only valid for multi-plane YCbCr formats.
|
| 1230 |
|
| 1231 | #define AFBC_FORMAT_MOD_BLOCK_SIZE_MASK 0xf
|
| 1232 | #define AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 (1ULL)
|
| 1233 | #define AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 (2ULL)
|
| 1234 | #define AFBC_FORMAT_MOD_BLOCK_SIZE_64x4 (3ULL)
|
| 1235 | #define AFBC_FORMAT_MOD_BLOCK_SIZE_32x8_64x4 (4ULL)
|
| 1236 |
|
| 1237 | |
| 1238 | * AFBC lossless colorspace transform
|
| 1239 | *
|
| 1240 | * Indicates that the buffer makes use of the AFBC lossless colorspace
|
| 1241 | * transform.
|
| 1242 |
|
| 1243 | #define AFBC_FORMAT_MOD_YTR (1ULL << 4)
|
| 1244 |
|
| 1245 | |
| 1246 | * AFBC block-split
|
| 1247 | *
|
| 1248 | * Indicates that the payload of each superblock is split. The second
|
| 1249 | * half of the payload is positioned at a predefined offset from the start
|
| 1250 | * of the superblock payload.
|
| 1251 |
|
| 1252 | #define AFBC_FORMAT_MOD_SPLIT (1ULL << 5)
|
| 1253 |
|
| 1254 | |
| 1255 | * AFBC sparse layout
|
| 1256 | *
|
| 1257 | * This flag indicates that the payload of each superblock must be stored at a
|
| 1258 | * predefined position relative to the other superblocks in the same AFBC
|
| 1259 | * buffer. This order is the same order used by the header buffer. In this mode
|
| 1260 | * each superblock is given the same amount of space as an uncompressed
|
| 1261 | * superblock of the particular format would require, rounding up to the next
|
| 1262 | * multiple of 128 bytes in size.
|
| 1263 |
|
| 1264 | #define AFBC_FORMAT_MOD_SPARSE (1ULL << 6)
|
| 1265 |
|
| 1266 | |
| 1267 | * AFBC copy-block restrict
|
| 1268 | *
|
| 1269 | * Buffers with this flag must obey the copy-block restriction. The restriction
|
| 1270 | * is such that there are no copy-blocks referring across the border of 8x8
|
| 1271 | * blocks. For the subsampled data the 8x8 limitation is also subsampled.
|
| 1272 |
|
| 1273 | #define AFBC_FORMAT_MOD_CBR (1ULL << 7)
|
| 1274 |
|
| 1275 | |
| 1276 | * AFBC tiled layout
|
| 1277 | *
|
| 1278 | * The tiled layout groups superblocks in 8x8 or 4x4 tiles, where all
|
| 1279 | * superblocks inside a tile are stored together in memory. 8x8 tiles are used
|
| 1280 | * for pixel formats up to and including 32 bpp while 4x4 tiles are used for
|
| 1281 | * larger bpp formats. The order between the tiles is scan line.
|
| 1282 | * When the tiled layout is used, the buffer size (in pixels) must be aligned
|
| 1283 | * to the tile size.
|
| 1284 |
|
| 1285 | #define AFBC_FORMAT_MOD_TILED (1ULL << 8)
|
| 1286 |
|
| 1287 | |
| 1288 | * AFBC solid color blocks
|
| 1289 | *
|
| 1290 | * Indicates that the buffer makes use of solid-color blocks, whereby bandwidth
|
| 1291 | * can be reduced if a whole superblock is a single color.
|
| 1292 |
|
| 1293 | #define AFBC_FORMAT_MOD_SC (1ULL << 9)
|
| 1294 |
|
| 1295 | |
| 1296 | * AFBC double-buffer
|
| 1297 | *
|
| 1298 | * Indicates that the buffer is allocated in a layout safe for front-buffer
|
| 1299 | * rendering.
|
| 1300 |
|
| 1301 | #define AFBC_FORMAT_MOD_DB (1ULL << 10)
|
| 1302 |
|
| 1303 | |
| 1304 | * AFBC buffer content hints
|
| 1305 | *
|
| 1306 | * Indicates that the buffer includes per-superblock content hints.
|
| 1307 |
|
| 1308 | #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
|
| 1309 |
|
| 1310 | |
| 1311 | *
|
| 1312 | * Indicates that the buffer is using AFBC uncompressed storage mode.
|
| 1313 | * In this mode all superblock payloads in the buffer use the uncompressed
|
| 1314 | * storage mode, which is usually only used for data which cannot be compressed.
|
| 1315 | * The buffer layout is the same as for AFBC buffers without USM set, this only
|
| 1316 | * affects the storage mode of the individual superblocks. Note that even a
|
| 1317 | * buffer without USM set may use uncompressed storage mode for some or all
|
| 1318 | * superblocks, USM just guarantees it for all.
|
| 1319 |
|
| 1320 | #define AFBC_FORMAT_MOD_USM (1ULL << 12)
|
| 1321 |
|
| 1322 | |
| 1323 | * Arm Fixed-Rate Compression (AFRC) modifiers
|
| 1324 | *
|
| 1325 | * AFRC is a proprietary fixed rate image compression protocol and format,
|
| 1326 | * designed to provide guaranteed bandwidth and memory footprint
|
| 1327 | * reductions in graphics and media use-cases.
|
| 1328 | *
|
| 1329 | * AFRC buffers consist of one or more planes, with the same components
|
| 1330 | * and meaning as an uncompressed buffer using the same pixel format.
|
| 1331 | *
|
| 1332 | * Within each plane, the pixel/luma/chroma values are grouped into
|
| 1333 | * "coding unit" blocks which are individually compressed to a
|
| 1334 | * fixed size (in bytes). All coding units within a given plane of a buffer
|
| 1335 | * store the same number of values, and have the same compressed size.
|
| 1336 | *
|
| 1337 | * The coding unit size is configurable, allowing different rates of compression.
|
| 1338 | *
|
| 1339 | * The start of each AFRC buffer plane must be aligned to an alignment granule which
|
| 1340 | * depends on the coding unit size.
|
| 1341 | *
|
| 1342 | * Coding Unit Size Plane Alignment
|
| 1343 | * ---------------- ---------------
|
| 1344 | * 16 bytes 1024 bytes
|
| 1345 | * 24 bytes 512 bytes
|
| 1346 | * 32 bytes 2048 bytes
|
| 1347 | *
|
| 1348 | * Coding units are grouped into paging tiles. AFRC buffer dimensions must be aligned
|
| 1349 | * to a multiple of the paging tile dimensions.
|
| 1350 | * The dimensions of each paging tile depend on whether the buffer is optimised for
|
| 1351 | * scanline (SCAN layout) or rotated (ROT layout) access.
|
| 1352 | *
|
| 1353 | * Layout Paging Tile Width Paging Tile Height
|
| 1354 | * ------ ----------------- ------------------
|
| 1355 | * SCAN 16 coding units 4 coding units
|
| 1356 | * ROT 8 coding units 8 coding units
|
| 1357 | *
|
| 1358 | * The dimensions of each coding unit depend on the number of components
|
| 1359 | * in the compressed plane and whether the buffer is optimised for
|
| 1360 | * scanline (SCAN layout) or rotated (ROT layout) access.
|
| 1361 | *
|
| 1362 | * Number of Components in Plane Layout Coding Unit Width Coding Unit Height
|
| 1363 | * ----------------------------- --------- ----------------- ------------------
|
| 1364 | * 1 SCAN 16 samples 4 samples
|
| 1365 | * Example: 16x4 luma samples in a 'Y' plane
|
| 1366 | * 16x4 chroma 'V' values, in the 'V' plane of a fully-planar YUV buffer
|
| 1367 | * ----------------------------- --------- ----------------- ------------------
|
| 1368 | * 1 ROT 8 samples 8 samples
|
| 1369 | * Example: 8x8 luma samples in a 'Y' plane
|
| 1370 | * 8x8 chroma 'V' values, in the 'V' plane of a fully-planar YUV buffer
|
| 1371 | * ----------------------------- --------- ----------------- ------------------
|
| 1372 | * 2 DONT CARE 8 samples 4 samples
|
| 1373 | * Example: 8x4 chroma pairs in the 'UV' plane of a semi-planar YUV buffer
|
| 1374 | * ----------------------------- --------- ----------------- ------------------
|
| 1375 | * 3 DONT CARE 4 samples 4 samples
|
| 1376 | * Example: 4x4 pixels in an RGB buffer without alpha
|
| 1377 | * ----------------------------- --------- ----------------- ------------------
|
| 1378 | * 4 DONT CARE 4 samples 4 samples
|
| 1379 | * Example: 4x4 pixels in an RGB buffer with alpha
|
| 1380 |
|
| 1381 |
|
| 1382 | #define DRM_FORMAT_MOD_ARM_TYPE_AFRC 0x02
|
| 1383 |
|
| 1384 | #define DRM_FORMAT_MOD_ARM_AFRC(__afrc_mode) \
|
| 1385 | DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AFRC, __afrc_mode)
|
| 1386 |
|
| 1387 | |
| 1388 | * AFRC coding unit size modifier.
|
| 1389 | *
|
| 1390 | * Indicates the number of bytes used to store each compressed coding unit for
|
| 1391 | * one or more planes in an AFRC encoded buffer. The coding unit size for chrominance
|
| 1392 | * is the same for both Cb and Cr, which may be stored in separate planes.
|
| 1393 | *
|
| 1394 | * AFRC_FORMAT_MOD_CU_SIZE_P0 indicates the number of bytes used to store
|
| 1395 | * each compressed coding unit in the first plane of the buffer. For RGBA buffers
|
| 1396 | * this is the only plane, while for semi-planar and fully-planar YUV buffers,
|
| 1397 | * this corresponds to the luma plane.
|
| 1398 | *
|
| 1399 | * AFRC_FORMAT_MOD_CU_SIZE_P12 indicates the number of bytes used to store
|
| 1400 | * each compressed coding unit in the second and third planes in the buffer.
|
| 1401 | * For semi-planar and fully-planar YUV buffers, this corresponds to the chroma plane(s).
|
| 1402 | *
|
| 1403 | * For single-plane buffers, AFRC_FORMAT_MOD_CU_SIZE_P0 must be specified
|
| 1404 | * and AFRC_FORMAT_MOD_CU_SIZE_P12 must be zero.
|
| 1405 | * For semi-planar and fully-planar buffers, both AFRC_FORMAT_MOD_CU_SIZE_P0 and
|
| 1406 | * AFRC_FORMAT_MOD_CU_SIZE_P12 must be specified.
|
| 1407 |
|
| 1408 | #define AFRC_FORMAT_MOD_CU_SIZE_MASK 0xf
|
| 1409 | #define AFRC_FORMAT_MOD_CU_SIZE_16 (1ULL)
|
| 1410 | #define AFRC_FORMAT_MOD_CU_SIZE_24 (2ULL)
|
| 1411 | #define AFRC_FORMAT_MOD_CU_SIZE_32 (3ULL)
|
| 1412 |
|
| 1413 | #define AFRC_FORMAT_MOD_CU_SIZE_P0(__afrc_cu_size) (__afrc_cu_size)
|
| 1414 | #define AFRC_FORMAT_MOD_CU_SIZE_P12(__afrc_cu_size) ((__afrc_cu_size) << 4)
|
| 1415 |
|
| 1416 | |
| 1417 | * AFRC scanline memory layout.
|
| 1418 | *
|
| 1419 | * Indicates if the buffer uses the scanline-optimised layout
|
| 1420 | * for an AFRC encoded buffer, otherwise, it uses the rotation-optimised layout.
|
| 1421 | * The memory layout is the same for all planes.
|
| 1422 |
|
| 1423 | #define AFRC_FORMAT_MOD_LAYOUT_SCAN (1ULL << 8)
|
| 1424 |
|
| 1425 | |
| 1426 | * Arm 16x16 Block U-Interleaved modifier
|
| 1427 | *
|
| 1428 | * This is used by Arm Mali Utgard and Midgard GPUs. It divides the image
|
| 1429 | * into 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
|
| 1430 | * in the block are reordered.
|
| 1431 |
|
| 1432 | #define DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \
|
| 1433 | DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 1ULL)
|
| 1434 |
|
| 1435 | |
| 1436 | * ARM 64k interleaved modifier
|
| 1437 | *
|
| 1438 | * This is used by ARM Mali v10+ GPUs. With this modifier, the plane is divided
|
| 1439 | * into 64k byte 1:1 or 2:1 -sided tiles. The 64k tiles are laid out linearly.
|
| 1440 | * Each 64k tile is divided into blocks of 16x16 texel blocks, which are
|
| 1441 | * themselves laid out linearly within a 64k tile. Then within each 16x16
|
| 1442 | * block, texel blocks are laid out according to U order, similar to
|
| 1443 | * 16X16_BLOCK_U_INTERLEAVED.
|
| 1444 | *
|
| 1445 | * Note that unlike 16X16_BLOCK_U_INTERLEAVED, the layout does not change
|
| 1446 | * depending on whether a format is compressed or not.
|
| 1447 |
|
| 1448 | #define DRM_FORMAT_MOD_ARM_INTERLEAVED_64K \
|
| 1449 | DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_MISC, 2ULL)
|
| 1450 |
|
| 1451 | |
| 1452 | * Allwinner tiled modifier
|
| 1453 | *
|
| 1454 | * This tiling mode is implemented by the VPU found on all Allwinner platforms,
|
| 1455 | * codenamed sunxi. It is associated with a YUV format that uses either 2 or 3
|
| 1456 | * planes.
|
| 1457 | *
|
| 1458 | * With this tiling, the luminance samples are disposed in tiles representing
|
| 1459 | * 32x32 pixels and the chrominance samples in tiles representing 32x64 pixels.
|
| 1460 | * The pixel order in each tile is linear and the tiles are disposed linearly,
|
| 1461 | * both in row-major order.
|
| 1462 |
|
| 1463 | #define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
|
| 1464 |
|
| 1465 | |
| 1466 | * Amlogic Video Framebuffer Compression modifiers
|
| 1467 | *
|
| 1468 | * Amlogic uses a proprietary lossless image compression protocol and format
|
| 1469 | * for their hardware video codec accelerators, either video decoders or
|
| 1470 | * video input encoders.
|
| 1471 | *
|
| 1472 | * It considerably reduces memory bandwidth while writing and reading
|
| 1473 | * frames in memory.
|
| 1474 | *
|
| 1475 | * The underlying storage is considered to be 3 components, 8bit or 10-bit
|
| 1476 | * per component YCbCr 420, single plane :
|
| 1477 | * - DRM_FORMAT_YUV420_8BIT
|
| 1478 | * - DRM_FORMAT_YUV420_10BIT
|
| 1479 | *
|
| 1480 | * The first 8 bits of the mode defines the layout, then the following 8 bits
|
| 1481 | * defines the options changing the layout.
|
| 1482 | *
|
| 1483 | * Not all combinations are valid, and different SoCs may support different
|
| 1484 | * combinations of layout and options.
|
| 1485 |
|
| 1486 | #define __fourcc_mod_amlogic_layout_mask 0xff
|
| 1487 | #define __fourcc_mod_amlogic_options_shift 8
|
| 1488 | #define __fourcc_mod_amlogic_options_mask 0xff
|
| 1489 |
|
| 1490 | #define DRM_FORMAT_MOD_AMLOGIC_FBC(__layout, __options) \
|
| 1491 | fourcc_mod_code(AMLOGIC, \
|
| 1492 | ((__layout) & __fourcc_mod_amlogic_layout_mask) | \
|
| 1493 | (((__options) & __fourcc_mod_amlogic_options_mask) \
|
| 1494 | << __fourcc_mod_amlogic_options_shift))
|
| 1495 |
|
| 1496 |
|
| 1497 |
|
| 1498 | |
| 1499 | * Amlogic FBC Basic Layout
|
| 1500 | *
|
| 1501 | * The basic layout is composed of:
|
| 1502 | * - a body content organized in 64x32 superblocks with 4096 bytes per
|
| 1503 | * superblock in default mode.
|
| 1504 | * - a 32 bytes per 128x64 header block
|
| 1505 | *
|
| 1506 | * This layout is transferrable between Amlogic SoCs supporting this modifier.
|
| 1507 |
|
| 1508 | #define AMLOGIC_FBC_LAYOUT_BASIC (1ULL)
|
| 1509 |
|
| 1510 | |
| 1511 | * Amlogic FBC Scatter Memory layout
|
| 1512 | *
|
| 1513 | * Indicates the header contains IOMMU references to the compressed
|
| 1514 | * frames content to optimize memory access and layout.
|
| 1515 | *
|
| 1516 | * In this mode, only the header memory address is needed, thus the
|
| 1517 | * content memory organization is tied to the current producer
|
| 1518 | * execution and cannot be saved/dumped neither transferrable between
|
| 1519 | * Amlogic SoCs supporting this modifier.
|
| 1520 | *
|
| 1521 | * Due to the nature of the layout, these buffers are not expected to
|
| 1522 | * be accessible by the user-space clients, but only accessible by the
|
| 1523 | * hardware producers and consumers.
|
| 1524 | *
|
| 1525 | * The user-space clients should expect a failure while trying to mmap
|
| 1526 | * the DMA-BUF handle returned by the producer.
|
| 1527 |
|
| 1528 | #define AMLOGIC_FBC_LAYOUT_SCATTER (2ULL)
|
| 1529 |
|
| 1530 |
|
| 1531 |
|
| 1532 | |
| 1533 | * Amlogic FBC Memory Saving mode
|
| 1534 | *
|
| 1535 | * Indicates the storage is packed when pixel size is multiple of word
|
| 1536 | * boundaries, i.e. 8bit should be stored in this mode to save allocation
|
| 1537 | * memory.
|
| 1538 | *
|
| 1539 | * This mode reduces body layout to 3072 bytes per 64x32 superblock with
|
| 1540 | * the basic layout and 3200 bytes per 64x32 superblock combined with
|
| 1541 | * the scatter layout.
|
| 1542 |
|
| 1543 | #define AMLOGIC_FBC_OPTION_MEM_SAVING (1ULL << 0)
|
| 1544 |
|
| 1545 | |
| 1546 | * Bits Parameter Notes
|
| 1547 | * ----- ------------------------ ---------------------------------------------
|
| 1548 | * 7: 0 TILE LAYOUT Values are MTK_FMT_MOD_TILE_*
|
| 1549 | * 15: 8 COMPRESSION Values are MTK_FMT_MOD_COMPRESS_*
|
| 1550 | * 23:16 10 BIT LAYOUT Values are MTK_FMT_MOD_10BIT_LAYOUT_*
|
| 1551 | *
|
| 1552 |
|
| 1553 |
|
| 1554 | #define DRM_FORMAT_MOD_MTK(__flags) fourcc_mod_code(MTK, __flags)
|
| 1555 |
|
| 1556 | |
| 1557 | * MediaTek Tiled Modifier
|
| 1558 | * The lowest 8 bits of the modifier is used to specify the tiling
|
| 1559 | * layout. Only the 16L_32S tiling is used for now, but we define an
|
| 1560 | * "untiled" version and leave room for future expansion.
|
| 1561 |
|
| 1562 | #define MTK_FMT_MOD_TILE_MASK 0xf
|
| 1563 | #define MTK_FMT_MOD_TILE_NONE 0x0
|
| 1564 | #define MTK_FMT_MOD_TILE_16L32S 0x1
|
| 1565 |
|
| 1566 | |
| 1567 | * Bits 8-15 specify compression options
|
| 1568 |
|
| 1569 | #define MTK_FMT_MOD_COMPRESS_MASK (0xf << 8)
|
| 1570 | #define MTK_FMT_MOD_COMPRESS_NONE (0x0 << 8)
|
| 1571 | #define MTK_FMT_MOD_COMPRESS_V1 (0x1 << 8)
|
| 1572 |
|
| 1573 | |
| 1574 | * Bits 16-23 specify how the bits of 10 bit formats are
|
| 1575 | * stored out in memory
|
| 1576 |
|
| 1577 | #define MTK_FMT_MOD_10BIT_LAYOUT_MASK (0xf << 16)
|
| 1578 | #define MTK_FMT_MOD_10BIT_LAYOUT_PACKED (0x0 << 16)
|
| 1579 | #define MTK_FMT_MOD_10BIT_LAYOUT_LSBTILED (0x1 << 16)
|
| 1580 | #define MTK_FMT_MOD_10BIT_LAYOUT_LSBRASTER (0x2 << 16)
|
| 1581 |
|
| 1582 |
|
| 1583 | #define DRM_FORMAT_MOD_MTK_16L_32S_TILE DRM_FORMAT_MOD_MTK(MTK_FMT_MOD_TILE_16L32S)
|
| 1584 |
|
| 1585 | |
| 1586 | * Apple GPU-tiled layouts.
|
| 1587 | *
|
| 1588 | * Apple GPUs support nonlinear tilings with optional lossless compression.
|
| 1589 | *
|
| 1590 | * GPU-tiled images are divided into 16KiB tiles:
|
| 1591 | *
|
| 1592 | * Bytes per pixel Tile size
|
| 1593 | * --------------- ---------
|
| 1594 | * 1 128x128
|
| 1595 | * 2 128x64
|
| 1596 | * 4 64x64
|
| 1597 | * 8 64x32
|
| 1598 | * 16 32x32
|
| 1599 | *
|
| 1600 | * Tiles are raster-order. Pixels within a tile are interleaved (Morton order).
|
| 1601 | *
|
| 1602 | * Compressed images pad the body to 128-bytes and are immediately followed by a
|
| 1603 | * metadata section. The metadata section rounds the image dimensions to
|
| 1604 | * powers-of-two and contains 8 bytes for each 16x16 compression subtile.
|
| 1605 | * Subtiles are interleaved (Morton order).
|
| 1606 | *
|
| 1607 | * All images are 128-byte aligned.
|
| 1608 | *
|
| 1609 | * These layouts fundamentally do not have meaningful strides. No matter how we
|
| 1610 | * specify strides for these layouts, userspace unaware of Apple image layouts
|
| 1611 | * will be unable to use correctly the specified stride for any purpose.
|
| 1612 | * Userspace aware of the image layouts do not use strides. The most "correct"
|
| 1613 | * convention would be setting the image stride to 0. Unfortunately, some
|
| 1614 | * software assumes the stride is at least (width * bytes per pixel). We
|
| 1615 | * therefore require that stride equals (width * bytes per pixel). Since the
|
| 1616 | * stride is arbitrary here, we pick the simplest convention.
|
| 1617 | *
|
| 1618 | * Although containing two sections, compressed image layouts are treated in
|
| 1619 | * software as a single plane. This is modelled after AFBC, a similar
|
| 1620 | * scheme. Attempting to separate the sections to be "explicit" in DRM would
|
| 1621 | * only generate more confusion, as software does not treat the image this way.
|
| 1622 | *
|
| 1623 | * For detailed information on the hardware image layouts, see
|
| 1624 | * https://docs.mesa3d.org/drivers/asahi.html#image-layouts
|
| 1625 |
|
| 1626 | #define DRM_FORMAT_MOD_APPLE_GPU_TILED fourcc_mod_code(APPLE, 1)
|
| 1627 | #define DRM_FORMAT_MOD_APPLE_GPU_TILED_COMPRESSED fourcc_mod_code(APPLE, 2)
|
| 1628 |
|
| 1629 | |
| 1630 | * AMD modifiers
|
| 1631 | *
|
| 1632 | * Memory layout:
|
| 1633 | *
|
| 1634 | * without DCC:
|
| 1635 | * - main surface
|
| 1636 | *
|
| 1637 | * with DCC & without DCC_RETILE:
|
| 1638 | * - main surface in plane 0
|
| 1639 | * - DCC surface in plane 1 (RB-aligned, pipe-aligned if DCC_PIPE_ALIGN is set)
|
| 1640 | *
|
| 1641 | * with DCC & DCC_RETILE:
|
| 1642 | * - main surface in plane 0
|
| 1643 | * - displayable DCC surface in plane 1 (not RB-aligned & not pipe-aligned)
|
| 1644 | * - pipe-aligned DCC surface in plane 2 (RB-aligned & pipe-aligned)
|
| 1645 | *
|
| 1646 | * For multi-plane formats the above surfaces get merged into one plane for
|
| 1647 | * each format plane, based on the required alignment only.
|
| 1648 | *
|
| 1649 | * Bits Parameter Notes
|
| 1650 | * ------- ------------------------ ---------------------------------------------
|
| 1651 | *
|
| 1652 | * DRM format modifier fields on AMD GPUs:
|
| 1653 | * 7:0 TILE_VERSION Values are AMD_FMT_MOD_TILE_VER_*
|
| 1654 | * 12:8 TILE Values are AMD_FMT_MOD_TILE_<version>_*
|
| 1655 | * 13 DCC Delta Color Compression, supported on GFX8 and newer
|
| 1656 | * 55:14 (chip specific) See below for details, depends on GFX block version
|
| 1657 | * 63:56 Vendor Value is DRM_FORMAT_MOD_VENDOR_AMD
|
| 1658 | *
|
| 1659 | * Chip specific fields on Gfx9 and newer:
|
| 1660 | * 14 DCC_RETILE
|
| 1661 | * 15 DCC_PIPE_ALIGN
|
| 1662 | * 16 DCC_INDEPENDENT_64B
|
| 1663 | * 17 DCC_INDEPENDENT_128B
|
| 1664 | * 19:18 DCC_MAX_COMPRESSED_BLOCK Values are AMD_FMT_MOD_DCC_BLOCK_*
|
| 1665 | * 20 DCC_CONSTANT_ENCODE
|
| 1666 | * 23:21 PIPE_XOR_BITS Only for some chips
|
| 1667 | * 26:24 BANK_XOR_BITS Only for some chips
|
| 1668 | * 29:27 PACKERS Only for some chips
|
| 1669 | * 32:30 RB Only for some chips
|
| 1670 | * 35:33 PIPE Only for some chips
|
| 1671 | * 55:36 - Reserved for future use, must be zero
|
| 1672 | *
|
| 1673 | * Chip specific fields on Gfx6-8:
|
| 1674 | * 16:14 MICROTILE Micro tile format
|
| 1675 | * 21:17 PIPE_CONFIG Number of pipes and how pipes are interleaved
|
| 1676 | * 24:22 TILE_SPLIT Tile split size
|
| 1677 | * 26:25 BANK_WIDTH Number of tiles in the X direction in the same bank
|
| 1678 | * 28:27 BANK_HEIGHT Number of tiles in the Y direction in the same bank
|
| 1679 | * 30:29 MACRO_TILE_ASPECT Macro tile aspect ratio
|
| 1680 | * 32:31 NUM_BANKS Number of banks
|
| 1681 | * 55:33 - Reserved for future use, must be zero
|
| 1682 | *
|
| 1683 |
|
| 1684 | #define AMD_FMT_MOD fourcc_mod_code(AMD, 0)
|
| 1685 |
|
| 1686 | #define IS_AMD_FMT_MOD(val) (((val) >> 56) == DRM_FORMAT_MOD_VENDOR_AMD)
|
| 1687 |
|
| 1688 | #define AMD_FMT_MOD_TILE_VER_GFX6 0
|
| 1689 | #define AMD_FMT_MOD_TILE_VER_GFX9 1
|
| 1690 | #define AMD_FMT_MOD_TILE_VER_GFX10 2
|
| 1691 | #define AMD_FMT_MOD_TILE_VER_GFX10_RBPLUS 3
|
| 1692 | #define AMD_FMT_MOD_TILE_VER_GFX11 4
|
| 1693 | #define AMD_FMT_MOD_TILE_VER_GFX12 5
|
| 1694 |
|
| 1695 | |
| 1696 | * Gfx6-8 tiling modes.
|
| 1697 | * A complete reference implementation is found in addrlib in the Mesa code base.
|
| 1698 | *
|
| 1699 | * - Microtiled modes (1D):
|
| 1700 | * Pixel data is organized into micro tiles of 8x8 pixels.
|
| 1701 | *
|
| 1702 | * - Macrotiled modes (2D):
|
| 1703 | * Micro tiles are further organized into macro tiles.
|
| 1704 | * These are optimized for even load distribution among memory channels.
|
| 1705 | *
|
| 1706 | * Note that only THIN1 modes are exposed here.
|
| 1707 | * THICK and XTHICK are for 3D images and not relevant to DRM format modifiers.
|
| 1708 |
|
| 1709 | #define AMD_FMT_MOD_TILE_GFX6_1D_TILED_THIN1 0x2
|
| 1710 | #define AMD_FMT_MOD_TILE_GFX6_2D_TILED_THIN1 0x4
|
| 1711 |
|
| 1712 | |
| 1713 | * 64K_S is the same for GFX9/GFX10/GFX10_RBPLUS and hence has GFX9 as canonical
|
| 1714 | * version.
|
| 1715 |
|
| 1716 | #define AMD_FMT_MOD_TILE_GFX9_64K_S 9
|
| 1717 |
|
| 1718 | |
| 1719 | * 64K_D for non-32 bpp is the same for GFX9/GFX10/GFX10_RBPLUS and hence has
|
| 1720 | * GFX9 as canonical version.
|
| 1721 | *
|
| 1722 | * 64K_D_2D on GFX12 is identical to 64K_D on GFX11.
|
| 1723 |
|
| 1724 | #define AMD_FMT_MOD_TILE_GFX9_64K_D 10
|
| 1725 | #define AMD_FMT_MOD_TILE_GFX9_4K_D_X 22
|
| 1726 | #define AMD_FMT_MOD_TILE_GFX9_64K_S_X 25
|
| 1727 | #define AMD_FMT_MOD_TILE_GFX9_64K_D_X 26
|
| 1728 | #define AMD_FMT_MOD_TILE_GFX9_64K_R_X 27
|
| 1729 | #define AMD_FMT_MOD_TILE_GFX11_256K_R_X 31
|
| 1730 |
|
| 1731 | |
| 1732 | * 0 - LINEAR
|
| 1733 | * 1 - 256B_2D - 2D block dimensions
|
| 1734 | * 2 - 4KB_2D
|
| 1735 | * 3 - 64KB_2D
|
| 1736 | * 4 - 256KB_2D
|
| 1737 | * 5 - 4KB_3D - 3D block dimensions
|
| 1738 | * 6 - 64KB_3D
|
| 1739 | * 7 - 256KB_3D
|
| 1740 |
|
| 1741 | #define AMD_FMT_MOD_TILE_GFX12_256B_2D 1
|
| 1742 | #define AMD_FMT_MOD_TILE_GFX12_4K_2D 2
|
| 1743 | #define AMD_FMT_MOD_TILE_GFX12_64K_2D 3
|
| 1744 | #define AMD_FMT_MOD_TILE_GFX12_256K_2D 4
|
| 1745 |
|
| 1746 | #define AMD_FMT_MOD_DCC_BLOCK_64B 0
|
| 1747 | #define AMD_FMT_MOD_DCC_BLOCK_128B 1
|
| 1748 | #define AMD_FMT_MOD_DCC_BLOCK_256B 2
|
| 1749 |
|
| 1750 | #define AMD_FMT_MOD_TILE_VERSION_SHIFT 0
|
| 1751 | #define AMD_FMT_MOD_TILE_VERSION_MASK 0xFF
|
| 1752 | #define AMD_FMT_MOD_TILE_SHIFT 8
|
| 1753 | #define AMD_FMT_MOD_TILE_MASK 0x1F
|
| 1754 |
|
| 1755 |
|
| 1756 | #define AMD_FMT_MOD_DCC_SHIFT 13
|
| 1757 | #define AMD_FMT_MOD_DCC_MASK 0x1
|
| 1758 |
|
| 1759 | |
| 1760 | * Whether to include two DCC surfaces, one which is rb & pipe aligned, and
|
| 1761 | * one which is not-aligned.
|
| 1762 |
|
| 1763 | #define AMD_FMT_MOD_DCC_RETILE_SHIFT 14
|
| 1764 | #define AMD_FMT_MOD_DCC_RETILE_MASK 0x1
|
| 1765 |
|
| 1766 |
|
| 1767 | #define AMD_FMT_MOD_DCC_PIPE_ALIGN_SHIFT 15
|
| 1768 | #define AMD_FMT_MOD_DCC_PIPE_ALIGN_MASK 0x1
|
| 1769 |
|
| 1770 | #define AMD_FMT_MOD_DCC_INDEPENDENT_64B_SHIFT 16
|
| 1771 | #define AMD_FMT_MOD_DCC_INDEPENDENT_64B_MASK 0x1
|
| 1772 | #define AMD_FMT_MOD_DCC_INDEPENDENT_128B_SHIFT 17
|
| 1773 | #define AMD_FMT_MOD_DCC_INDEPENDENT_128B_MASK 0x1
|
| 1774 | #define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_SHIFT 18
|
| 1775 | #define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_MASK 0x3
|
| 1776 |
|
| 1777 | |
| 1778 | * DCC supports embedding some clear colors directly in the DCC surface.
|
| 1779 | * However, on older GPUs the rendering HW ignores the embedded clear color
|
| 1780 | * and prefers the driver provided color. This necessitates doing a fastclear
|
| 1781 | * eliminate operation before a process transfers control.
|
| 1782 | *
|
| 1783 | * If this bit is set that means the fastclear eliminate is not needed for these
|
| 1784 | * embeddable colors.
|
| 1785 |
|
| 1786 | #define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_SHIFT 20
|
| 1787 | #define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_MASK 0x1
|
| 1788 |
|
| 1789 | |
| 1790 | * The below fields are for accounting for per GPU differences. These are only
|
| 1791 | * relevant for GFX9 and later and if the tile field is *_X/_T.
|
| 1792 | *
|
| 1793 | * PIPE_XOR_BITS = always needed
|
| 1794 | * BANK_XOR_BITS = only for TILE_VER_GFX9
|
| 1795 | * PACKERS = only for TILE_VER_GFX10_RBPLUS
|
| 1796 | * RB = only for TILE_VER_GFX9 & DCC
|
| 1797 | * PIPE = only for TILE_VER_GFX9 & DCC & (DCC_RETILE | DCC_PIPE_ALIGN)
|
| 1798 |
|
| 1799 | #define AMD_FMT_MOD_PIPE_XOR_BITS_SHIFT 21
|
| 1800 | #define AMD_FMT_MOD_PIPE_XOR_BITS_MASK 0x7
|
| 1801 | #define AMD_FMT_MOD_BANK_XOR_BITS_SHIFT 24
|
| 1802 | #define AMD_FMT_MOD_BANK_XOR_BITS_MASK 0x7
|
| 1803 | #define AMD_FMT_MOD_PACKERS_SHIFT 27
|
| 1804 | #define AMD_FMT_MOD_PACKERS_MASK 0x7
|
| 1805 | #define AMD_FMT_MOD_RB_SHIFT 30
|
| 1806 | #define AMD_FMT_MOD_RB_MASK 0x7
|
| 1807 | #define AMD_FMT_MOD_PIPE_SHIFT 33
|
| 1808 | #define AMD_FMT_MOD_PIPE_MASK 0x7
|
| 1809 |
|
| 1810 | |
| 1811 | * MICRO_TILE_MODE, 3 bits. Determines the micro tile format.
|
| 1812 | * Only relevant to Gfx6-8.
|
| 1813 | *
|
| 1814 | * DISPLAY - Displayable tiling
|
| 1815 | * THIN - Non-displayable tiling, a.k.a thin micro tiling
|
| 1816 | * DEPTH, THICK - not exposed, not relevant to DRM format modifier use cases
|
| 1817 | * ROTATED - not exposed, not implemented in Linux or Mesa
|
| 1818 |
|
| 1819 | #define AMD_FMT_MOD_MICROTILE_SHIFT 14ULL
|
| 1820 | #define AMD_FMT_MOD_MICROTILE_MASK 0x7
|
| 1821 |
|
| 1822 | #define AMD_FMT_MOD_MICROTILE_DISPLAY 0x0
|
| 1823 | #define AMD_FMT_MOD_MICROTILE_THIN 0x1
|
| 1824 |
|
| 1825 | |
| 1826 | * PIPE_CONFIG, 5 bits. Number of pipes and how pipes are interleaved on the surface,
|
| 1827 | * which means the shader engine tile size and packer tile size.
|
| 1828 | * Typically matches the number of memory channels, or number of RBs.
|
| 1829 | * Only relevant to Gfx6-8 macro tiled modes.
|
| 1830 | *
|
| 1831 | * P<n>_<a>x<b>_<c>x<d>
|
| 1832 | * where:
|
| 1833 | * <n> - number of pipes
|
| 1834 | * <a>x<b> - shader engine tile size
|
| 1835 | * <c>x<d> - packer tile size
|
| 1836 |
|
| 1837 | #define AMD_FMT_MOD_PIPE_CONFIG_SHIFT 17ULL
|
| 1838 | #define AMD_FMT_MOD_PIPE_CONFIG_MASK 0x1f
|
| 1839 |
|
| 1840 | #define AMD_FMT_MOD_PIPE_CONFIG_P2 0x0
|
| 1841 | #define AMD_FMT_MOD_PIPE_CONFIG_P4_8x16 0x4
|
| 1842 | #define AMD_FMT_MOD_PIPE_CONFIG_P4_16x16 0x5
|
| 1843 | #define AMD_FMT_MOD_PIPE_CONFIG_P4_16x32 0x6
|
| 1844 | #define AMD_FMT_MOD_PIPE_CONFIG_P4_32x32 0x7
|
| 1845 | #define AMD_FMT_MOD_PIPE_CONFIG_P8_16x16_8x16 0x8
|
| 1846 | #define AMD_FMT_MOD_PIPE_CONFIG_P8_16x32_8x16 0x9
|
| 1847 | #define AMD_FMT_MOD_PIPE_CONFIG_P8_32x32_8x16 0xa
|
| 1848 | #define AMD_FMT_MOD_PIPE_CONFIG_P8_16x32_16x16 0xb
|
| 1849 | #define AMD_FMT_MOD_PIPE_CONFIG_P8_32x32_16x16 0xc
|
| 1850 | #define AMD_FMT_MOD_PIPE_CONFIG_P8_32x32_16x32 0xd
|
| 1851 | #define AMD_FMT_MOD_PIPE_CONFIG_P8_32x64_32x32 0xe
|
| 1852 | #define AMD_FMT_MOD_PIPE_CONFIG_P16_32x32_8x16 0x10
|
| 1853 | #define AMD_FMT_MOD_PIPE_CONFIG_P16_32x32_16x16 0x11
|
| 1854 |
|
| 1855 | |
| 1856 | * TILE_SPLIT, 3 bits.
|
| 1857 | * Only relevant to Gfx6-8 macro tiled modes.
|
| 1858 | *
|
| 1859 | * On GFX6 (or with depth tiling modes on GFX7 and newer),
|
| 1860 | * the GFX block uses the GB_TILE_MODE.TILE_SPLIT field directly.
|
| 1861 | *
|
| 1862 | * On GFX7 and newer with non-depth tiling modes, the GFX block uses a
|
| 1863 | * split factor which is stored in the GB_TILE_MODE.SAMPLE_SPLIT field.
|
| 1864 | * SAMPLE_SPLIT may be: 0 - 1 byte; 1 - 2 bytes; 2 - 4 bytes; 3 - 8 bytes.
|
| 1865 | * The actual tile size and tile split bytes are calculated as follows:
|
| 1866 | *
|
| 1867 | * bpp = ... <- bits per pixel in the current image
|
| 1868 | * thickness = ... <- depends on array mode; may be: 1, 4, 8
|
| 1869 | * num_samples = ... <- number of samples in the current image
|
| 1870 | * tile_size_pixels = 8 * 8
|
| 1871 | * tile_bytes_1x = thickness * tile_size_pixels * bpp / 8
|
| 1872 | * sample_split_factor = 1 << SAMPLE_SPLIT
|
| 1873 | * tile_split_bytes = clamp(tile_bytes_1x * sample_split_factor, 256, dram_row_size_bytes)
|
| 1874 | * tile_bytes = clamp(tile_bytes_1x * num_samples, 64, tile_split_bytes)
|
| 1875 | *
|
| 1876 | * In both cases, the display block (DCE) has no SAMPLE_SPLIT
|
| 1877 | * and just needs the tile split bytes in the GRPH_CONTROL.GRPH_TILE_SPLIT field.
|
| 1878 | * To maximize compatibility between GFX6-7, we don't include the SAMPLE_SPLIT
|
| 1879 | * in the format modifiers.
|
| 1880 | *
|
| 1881 | * The actual tile split in bytes is: 64 << field value
|
| 1882 | * Possible values of this field:
|
| 1883 | *
|
| 1884 | * 0 - Tile split is 64 bytes
|
| 1885 | * 1 - Tile split is 128 bytes
|
| 1886 | * 2 - Tile split is 256 bytes
|
| 1887 | * 3 - Tile split is 512 bytes
|
| 1888 | * 4 - Tile split is 1 KiB
|
| 1889 | * 5 - Tile split is 2 KiB
|
| 1890 | * 6 - Tile split is 4 KiB
|
| 1891 |
|
| 1892 | #define AMD_FMT_MOD_TILE_SPLIT_SHIFT 22ULL
|
| 1893 | #define AMD_FMT_MOD_TILE_SPLIT_MASK 0x7
|
| 1894 |
|
| 1895 | |
| 1896 | * BANK_WIDTH, 2 bits. Number of tiles in the X direction in the same bank.
|
| 1897 | * Only relevant to Gfx6-8 macro tiled modes.
|
| 1898 | * The actual bank width is: 1 << field value
|
| 1899 | * Possible values:
|
| 1900 | *
|
| 1901 | * 0 - bank width is 1
|
| 1902 | * 1 - bank width is 2
|
| 1903 | * 2 - bank width is 4
|
| 1904 | * 3 - bank width is 8
|
| 1905 |
|
| 1906 | #define AMD_FMT_MOD_BANK_WIDTH_SHIFT 25ULL
|
| 1907 | #define AMD_FMT_MOD_BANK_WIDTH_MASK 0x3
|
| 1908 |
|
| 1909 | |
| 1910 | * BANK_HEIGHT, 2 bits. Number of tiles in the Y direction in the same bank.
|
| 1911 | * Only relevant to Gfx6-8 macro tiled modes.
|
| 1912 | * The actual bank height is: 1 << field value
|
| 1913 | * Possible values:
|
| 1914 | *
|
| 1915 | * 0 - bank height is 1
|
| 1916 | * 1 - bank height is 2
|
| 1917 | * 2 - bank height is 4
|
| 1918 | * 3 - bank height is 8
|
| 1919 |
|
| 1920 | #define AMD_FMT_MOD_BANK_HEIGHT_SHIFT 27ULL
|
| 1921 | #define AMD_FMT_MOD_BANK_HEIGHT_MASK 0x3
|
| 1922 |
|
| 1923 | |
| 1924 | * MACRO_TILE_ASPECT, 2 bits. Macro tile aspect ratio.
|
| 1925 | * Only relevant to Gfx6-8 macro tiled modes.
|
| 1926 | * Possible values:
|
| 1927 | *
|
| 1928 | * 0 - aspect ratio is 1:1
|
| 1929 | * 1 - aspect ratio is 4:1
|
| 1930 | * 2 - aspect ratio is 16:1
|
| 1931 | * 3 - aspect ratio is 64:1
|
| 1932 |
|
| 1933 | #define AMD_FMT_MOD_MACRO_TILE_ASPECT_SHIFT 29ULL
|
| 1934 | #define AMD_FMT_MOD_MACRO_TILE_ASPECT_MASK 0x3
|
| 1935 |
|
| 1936 | |
| 1937 | * NUM_BANKS, 2 bits. Number of banks.
|
| 1938 | * Only relevant to Gfx6-8 macro tiled modes.
|
| 1939 | * The actual number of banks is: 2 << field value
|
| 1940 | * Possible values:
|
| 1941 | *
|
| 1942 | * 0 - number of banks is 2
|
| 1943 | * 1 - number of banks is 4
|
| 1944 | * 2 - number of banks is 8
|
| 1945 | * 3 - number of banks is 16
|
| 1946 |
|
| 1947 | #define AMD_FMT_MOD_NUM_BANKS_SHIFT 31ULL
|
| 1948 | #define AMD_FMT_MOD_NUM_BANKS_MASK 0x3
|
| 1949 |
|
| 1950 | #define AMD_FMT_MOD_SET(field, value) \
|
| 1951 | ((__u64)(value) << AMD_FMT_MOD_##field##_SHIFT)
|
| 1952 | #define AMD_FMT_MOD_GET(field, value) \
|
| 1953 | (((value) >> AMD_FMT_MOD_##field##_SHIFT) & AMD_FMT_MOD_##field##_MASK)
|
| 1954 | #define AMD_FMT_MOD_CLEAR(field) \
|
| 1955 | (~((__u64)AMD_FMT_MOD_##field##_MASK << AMD_FMT_MOD_##field##_SHIFT))
|
| 1956 |
|
| 1957 | #if defined(__cplusplus)
|
| 1958 | }
|
| 1959 | #endif
|
| 1960 |
|
| 1961 | #endif
|