Arm Framebuffer Compression (AFBC)

AFBC의 목적과 modifier 계약

Arm Framebuffer Compression(AFBC)은 proprietary lossless image compression protocol이자 format이다. 세밀한 random access를 제공하고 IP block 사이에서 전송하는 data 양을 줄인다.

AFBC를 지원하는 driver는 `drm_fourcc.h`에 정의된 AFBC format modifier로 기능을 enable할 수 있다. 관련 symbol은 `DRM_FORMAT_MOD_ARM_AFBC(*)`다. Fourcc와 modifier의 조합이 buffer의 component·plane layout을 함께 표현한다.

서로 다른 AFBC producer와 consumer가 호환되려면 모든 modifier 사용자가 이 문서의 지침을 따라야 한다. 압축이 lossless라는 사실만으로 memory layout의 상호운용성이 보장되는 것은 아니며, 양쪽이 component order와 plane 수를 동일하게 해석해야 한다.

.. 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.

Component 순서와 YTR

AFBC stream은 여러 component를 담을 수 있으며 component는 R, G, B, X, A, Y, Cb, Cr 같은 color channel에 대응한다. 정상 동작을 위해 encoder와 decoder의 input/output channel assignment가 일치해야 한다. 순서가 다르면 consumer가 decode된 data를 잘못 해석한다.

Lossless colorspace transform인 `AFBC_FORMAT_MOD_YTR`을 사용할 때 component order는 반드시 Component 0 R, Component 1 G, Component 2 B여야 한다. RGB buffer에서는 최대 compression efficiency를 위해 YTR을 enable하는 것이 권장된다.

Component order는 `fourcc:modifier` pair의 fourcc code로 전달한다. 일반적으로 component 0은 대응하는 linear format의 least-significant bits에 있다. `DRM_FORMAT_ABGR8888`은 R(8), G(8), B(8), A(8), `DRM_FORMAT_BGR888`은 R(8), G(8), B(8), `DRM_FORMAT_YUYV`는 Y(8), Cb(8, 2x1 subsampled), Cr(8, 2x1 subsampled) 순서다.

AFBC는 `X` component를 다른 component와 다르게 취급하지 않는다. 따라서 `DRM_FORMAT_XBGR8888`도 R, G, B, X의 네 component로 encode된다. 사용하지 않는 X channel은 compression efficiency를 낮추므로 피하는 것이 좋다.

Encoder나 decoder가 네 번째 component를 요구한다면 equivalent alpha format을 사용하고 모든 alpha bit를 1로 설정하는 것이 권장된다. 네 번째 component가 필요하지 않다면 alpha가 없는 `DRM_FORMAT_BGR888` 같은 format을 사용할 수 있다.

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.

AFBC plane 수와 component 배치

Linear layout에서 일반적으로 multi-planar인 YUV 420 같은 format은 AFBC에서도 하나 또는 여러 plane으로 encode할 수 있다. 올바른 decode를 위해 encoder와 decoder는 component order뿐 아니라 plane 수에도 합의해야 한다.

AFBC buffer의 encoded plane 수는 fourcc code로 결정하며 unmodified linear format의 plane 수와 일치한다. 각 plane 내부의 component order 역시 fourcc를 따른다.

`DRM_FORMAT_YUYV`는 `nplanes = 1`이다. Plane 0에 Y(8), Cb(8, 2x1 subsampled), Cr(8, 2x1 subsampled) 세 component가 들어간다. `DRM_FORMAT_NV12`는 `nplanes = 2`이며 Plane 0은 Y(8), Plane 1은 Cb(8, 2x1 subsampled)와 Cr(8, 2x1 subsampled)를 담는다.

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 canonical format

AFBC device 사이의 최대 호환성을 위해 아래 표는 canonical format을 정의한다. 목록에 있는 format은 AFBC modifier와 함께 사용할 때 정확히 지정된 plane·component 구조를 따라야 한다. 목록에 없는 format은 피해야 한다.

RGB 계열은 component bit depth와 alpha 유무를 명시한다. YCbCr 계열은 4:4:4, 4:2:2, 4:2:0 sampling, single-plane 또는 two-plane 배치, 8-bit 또는 10-bit component를 구분한다.

Two-plane format인 NV16, P210, NV12, P010은 Plane 0에 Y 하나를 두고 Plane 1에 Cb와 Cr을 둔다. YUYV, Y210, YUV420_8BIT, YUV420_10BIT은 한 plane 안에 Y·Cb·Cr 세 component를 둔다.

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)