Documentation/gpu/afbc.rst
Source file repositories/reference/linux-study-clean/Documentation/gpu/afbc.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/gpu/afbc.rst- Extension
.rst- Size
- 7431 bytes
- Lines
- 236
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. 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
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.