Based on kernel version 6.11
. Page generated on 2024-09-24 08:21 EST
.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 | .. SPDX-License-Identifier: GPL-2.0+ =================================== Arm Framebuffer Compression (AFBC) =================================== AFBC is a proprietary lossless image compression protocol and format. It provides fine-grained random access and minimizes the amount of data transferred between IP blocks. AFBC can be enabled on drivers which support it via use of the AFBC format modifiers defined in drm_fourcc.h. See DRM_FORMAT_MOD_ARM_AFBC(*). All users of the AFBC modifiers must follow the usage guidelines laid out in this document, to ensure compatibility across different AFBC producers and consumers. Components and Ordering ======================= AFBC streams can contain several components - where a component corresponds to a color channel (i.e. R, G, B, X, A, Y, Cb, Cr). The assignment of input/output color channels must be consistent between the encoder and the decoder for correct operation, otherwise the consumer will interpret the decoded data incorrectly. Furthermore, when the lossless colorspace transform is used (AFBC_FORMAT_MOD_YTR, which should be enabled for RGB buffers for maximum compression efficiency), the component order must be: * Component 0: R * Component 1: G * Component 2: B The component ordering is communicated via the fourcc code in the fourcc:modifier pair. In general, component '0' is considered to reside in the least-significant bits of the corresponding linear format. For example, COMP(bits): * DRM_FORMAT_ABGR8888 * Component 0: R(8) * Component 1: G(8) * Component 2: B(8) * Component 3: A(8) * DRM_FORMAT_BGR888 * Component 0: R(8) * Component 1: G(8) * Component 2: B(8) * DRM_FORMAT_YUYV * Component 0: Y(8) * Component 1: Cb(8, 2x1 subsampled) * Component 2: Cr(8, 2x1 subsampled) In AFBC, 'X' components are not treated any differently from any other component. Therefore, an AFBC buffer with fourcc DRM_FORMAT_XBGR8888 encodes with 4 components, like so: * DRM_FORMAT_XBGR8888 * Component 0: R(8) * Component 1: G(8) * Component 2: B(8) * Component 3: X(8) Please note, however, that the inclusion of a "wasted" 'X' channel is bad for compression efficiency, and so it's recommended to avoid formats containing 'X' bits. If a fourth component is required/expected by the encoder/decoder, then it is recommended to instead use an equivalent format with alpha, setting all alpha bits to '1'. If there is no requirement for a fourth component, then a format which doesn't include alpha can be used, e.g. DRM_FORMAT_BGR888. Number of Planes ================ Formats which are typically multi-planar in linear layouts (e.g. YUV 420), can be encoded into one, or multiple, AFBC planes. As with component order, the encoder and decoder must agree about the number of planes in order to correctly decode the buffer. The fourcc code is used to determine the number of encoded planes in an AFBC buffer, matching the number of planes for the linear (unmodified) format. Within each plane, the component ordering also follows the fourcc code: For example: * DRM_FORMAT_YUYV: nplanes = 1 * Plane 0: * Component 0: Y(8) * Component 1: Cb(8, 2x1 subsampled) * Component 2: Cr(8, 2x1 subsampled) * DRM_FORMAT_NV12: nplanes = 2 * Plane 0: * Component 0: Y(8) * Plane 1: * Component 0: Cb(8, 2x1 subsampled) * Component 1: Cr(8, 2x1 subsampled) Cross-device interoperability ============================= For maximum compatibility across devices, the table below defines canonical formats for use between AFBC-enabled devices. Formats which are listed here must be used exactly as specified when using the AFBC modifiers. Formats which are not listed should be avoided. .. flat-table:: AFBC formats * - Fourcc code - Description - Planes/Components * - DRM_FORMAT_ABGR2101010 - 10-bit per component RGB, with 2-bit alpha - Plane 0: 4 components * Component 0: R(10) * Component 1: G(10) * Component 2: B(10) * Component 3: A(2) * - DRM_FORMAT_ABGR8888 - 8-bit per component RGB, with 8-bit alpha - Plane 0: 4 components * Component 0: R(8) * Component 1: G(8) * Component 2: B(8) * Component 3: A(8) * - DRM_FORMAT_BGR888 - 8-bit per component RGB - Plane 0: 3 components * Component 0: R(8) * Component 1: G(8) * Component 2: B(8) * - DRM_FORMAT_BGR565 - 5/6-bit per component RGB - Plane 0: 3 components * Component 0: R(5) * Component 1: G(6) * Component 2: B(5) * - DRM_FORMAT_ABGR1555 - 5-bit per component RGB, with 1-bit alpha - Plane 0: 4 components * Component 0: R(5) * Component 1: G(5) * Component 2: B(5) * Component 3: A(1) * - DRM_FORMAT_VUY888 - 8-bit per component YCbCr 444, single plane - Plane 0: 3 components * Component 0: Y(8) * Component 1: Cb(8) * Component 2: Cr(8) * - DRM_FORMAT_VUY101010 - 10-bit per component YCbCr 444, single plane - Plane 0: 3 components * Component 0: Y(10) * Component 1: Cb(10) * Component 2: Cr(10) * - DRM_FORMAT_YUYV - 8-bit per component YCbCr 422, single plane - Plane 0: 3 components * Component 0: Y(8) * Component 1: Cb(8, 2x1 subsampled) * Component 2: Cr(8, 2x1 subsampled) * - DRM_FORMAT_NV16 - 8-bit per component YCbCr 422, two plane - Plane 0: 1 component * Component 0: Y(8) Plane 1: 2 components * Component 0: Cb(8, 2x1 subsampled) * Component 1: Cr(8, 2x1 subsampled) * - DRM_FORMAT_Y210 - 10-bit per component YCbCr 422, single plane - Plane 0: 3 components * Component 0: Y(10) * Component 1: Cb(10, 2x1 subsampled) * Component 2: Cr(10, 2x1 subsampled) * - DRM_FORMAT_P210 - 10-bit per component YCbCr 422, two plane - Plane 0: 1 component * Component 0: Y(10) Plane 1: 2 components * Component 0: Cb(10, 2x1 subsampled) * Component 1: Cr(10, 2x1 subsampled) * - DRM_FORMAT_YUV420_8BIT - 8-bit per component YCbCr 420, single plane - Plane 0: 3 components * Component 0: Y(8) * Component 1: Cb(8, 2x2 subsampled) * Component 2: Cr(8, 2x2 subsampled) * - DRM_FORMAT_YUV420_10BIT - 10-bit per component YCbCr 420, single plane - Plane 0: 3 components * Component 0: Y(10) * Component 1: Cb(10, 2x2 subsampled) * Component 2: Cr(10, 2x2 subsampled) * - DRM_FORMAT_NV12 - 8-bit per component YCbCr 420, two plane - Plane 0: 1 component * Component 0: Y(8) Plane 1: 2 components * Component 0: Cb(8, 2x2 subsampled) * Component 1: Cr(8, 2x2 subsampled) * - DRM_FORMAT_P010 - 10-bit per component YCbCr 420, two plane - Plane 0: 1 component * Component 0: Y(10) Plane 1: 2 components * Component 0: Cb(10, 2x2 subsampled) * Component 1: Cr(10, 2x2 subsampled) |