On Fri, 21 Feb 2020 10:08:42 +0100 Neil Armstrong narmstrong@baylibre.com wrote:
Amlogic uses a proprietary lossless image compression protocol and format for their hardware video codec accelerators, either video decoders or video input encoders.
It considerably reduces memory bandwidth while writing and reading frames in memory.
The underlying storage is considered to be 3 components, 8bit or 10-bit per component, YCbCr 420, single plane :
- DRM_FORMAT_YUV420_8BIT
- DRM_FORMAT_YUV420_10BIT
This modifier will be notably added to DMA-BUF frames imported from the V4L2 Amlogic VDEC decoder.
At least two options are supported :
- Scatter mode: the buffer is filled with a IOMMU scatter table referring to the encoder current memory layout. This mode if more efficient in terms of memory allocation but frames are not dumpable and only valid during until the buffer is freed and back in control of the encoder
- Memory saving: when the pixel bpp is 8b, the size of the superblock can be reduced, thus saving memory.
Signed-off-by: Neil Armstrong narmstrong@baylibre.com
include/uapi/drm/drm_fourcc.h | 56 +++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 8bc0b31597d8..8a6e87bacadb 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -309,6 +309,7 @@ extern "C" { #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07 #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 +#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
/* add more to the end as needed */
@@ -804,6 +805,61 @@ extern "C" { */ #define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
+/*
- Amlogic Video Framebuffer Compression modifiers
- Amlogic uses a proprietary lossless image compression protocol and format
- for their hardware video codec accelerators, either video decoders or
- video input encoders.
- It considerably reduces memory bandwidth while writing and reading
- frames in memory.
- Implementation details may be platform and SoC specific, and shared
- between the producer and the decoder on the same platform.
Hi,
after a lengthy IRC discussion on #dri-devel, this "may be platform and SoC specific" is a problem.
It can be an issue in two ways:
- If something in the data acts like a sub-modifier, then advertising support for one modifier does not really tell if the data layout is supported or not.
- If you need to know the platform and/or SoC to be able to interpret the data, it means the modifier is ill-defined and cannot be used in inter-machine communication (e.g. Pipewire).
Neil mentioned the data contains a "header" that further specifies things, but there is no specification about the header itself. Therefore I don't think we can even know if the header contains something that acts like a sub-modifier or not.
All this sounds like the modifier definitions here are not enough to fully interpret the data. At the very least I would expect a reference to a document explaining the "header", or even better, a kernel ReST doc.
I wonder if this is at all suitable as a DRM format modifier as is. I have been assuming that a modifier together with all the usual FB parameters should be enough to interpret the stored data, but in this case I have doubt it actually is.
I have no problem with proprietary data layouts as long as they are fully specified.
I do feel like I would not be able to write a software decoder for this set of modifiers given the details below.
Thanks, pq
- The underlying storage is considered to be 3 components, 8bit or 10-bit
- per component YCbCr 420, single plane :
- DRM_FORMAT_YUV420_8BIT
- DRM_FORMAT_YUV420_10BIT
- The classic memory storage is composed of:
- a body content organized in 64x32 superblocks with 4096 bytes per
- superblock in default mode.
- a 32 bytes per 128x64 header block
- */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_DEFAULT fourcc_mod_code(AMLOGIC, 0)
+/*
- Amlogic Video Framebuffer Compression Options
- Two optional features are available which may not supported/used on every
- SoCs and Compressed Framebuffer producers.
- */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC(__modes) fourcc_mod_code(AMLOGIC, __modes)
+/*
- Amlogic FBC Scatter Memory layout
- Indicates the header contains IOMMU references to the compressed
- frames content to optimize memory access and layout.
- In this mode, only the header memory address is needed, thus the
- content memory organization is tied to the current producer
- execution and cannot be saved/dumped.
- */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_SCATTER (1ULL << 0)
+/*
- Amlogic FBC Memory Saving mode
- Indicates the storage is packed when pixel size is multiple of word
- boudaries, i.e. 8bit should be stored in this mode to save allocation
- memory.
- This mode reduces body layout to 3072 bytes per 64x32 superblock and
- 3200 bytes per 64x32 superblock combined with scatter mode.
- */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING (1ULL << 1)
#if defined(__cplusplus) } #endif