[igt-dev] [PATCH i-g-t 1/2] drm-uapi: Re-synchronize drm_fourcc.h with kernel.

Petri Latvala petri.latvala at intel.com
Fri Jun 11 05:54:52 UTC 2021


On Fri, Jun 11, 2021 at 06:21:22AM +0200, Mario Kleiner wrote:
> This aligns IGT's drm_fourcc.h to the latest kernel commit ff92ecf575a9
> ("drm/fourcc: Add 16 bpc fixed point framebuffer formats.")
> in drm-next for upcoming Linux 5.14.
> 
> Needed for lib/igt_fb support for testing of 16 bpc fixed point formats.
> 
> Signed-off-by: Mario Kleiner <mario.kleiner.de at gmail.com>
> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Cc: Alex Deucher <alexander.deucher at amd.com>


Acked-by: Petri Latvala <petri.latvala at intel.com>


> ---
>  include/drm-uapi/drm_fourcc.h | 72 +++++++++++++++++++++++++++++++++--
>  1 file changed, 68 insertions(+), 4 deletions(-)
> 
> diff --git a/include/drm-uapi/drm_fourcc.h b/include/drm-uapi/drm_fourcc.h
> index a7bc058c..f7156322 100644
> --- a/include/drm-uapi/drm_fourcc.h
> +++ b/include/drm-uapi/drm_fourcc.h
> @@ -58,6 +58,30 @@ extern "C" {
>   * may preserve meaning - such as number of planes - from the fourcc code,
>   * whereas others may not.
>   *
> + * Modifiers must uniquely encode buffer layout. In other words, a buffer must
> + * match only a single modifier. A modifier must not be a subset of layouts of
> + * another modifier. For instance, it's incorrect to encode pitch alignment in
> + * a modifier: a buffer may match a 64-pixel aligned modifier and a 32-pixel
> + * aligned modifier. That said, modifiers can have implicit minimal
> + * requirements.
> + *
> + * For modifiers where the combination of fourcc code and modifier can alias,
> + * a canonical pair needs to be defined and used by all drivers. Preferred
> + * combinations are also encouraged where all combinations might lead to
> + * confusion and unnecessarily reduced interoperability. An example for the
> + * latter is AFBC, where the ABGR layouts are preferred over ARGB layouts.
> + *
> + * There are two kinds of modifier users:
> + *
> + * - Kernel and user-space drivers: for drivers it's important that modifiers
> + *   don't alias, otherwise two drivers might support the same format but use
> + *   different aliases, preventing them from sharing buffers in an efficient
> + *   format.
> + * - Higher-level programs interfacing with KMS/GBM/EGL/Vulkan/etc: these users
> + *   see modifiers as opaque tokens they can check for equality and intersect.
> + *   These users musn't need to know to reason about the modifier value
> + *   (i.e. they are not expected to extract information out of the modifier).
> + *
>   * Vendors should document their modifier usage in as much detail as
>   * possible, to ensure maximum compatibility across devices, drivers and
>   * applications.
> @@ -144,6 +168,13 @@ extern "C" {
>  #define DRM_FORMAT_RGBA1010102	fourcc_code('R', 'A', '3', '0') /* [31:0] R:G:B:A 10:10:10:2 little endian */
>  #define DRM_FORMAT_BGRA1010102	fourcc_code('B', 'A', '3', '0') /* [31:0] B:G:R:A 10:10:10:2 little endian */
>  
> +/* 64 bpp RGB */
> +#define DRM_FORMAT_XRGB16161616	fourcc_code('X', 'R', '4', '8') /* [63:0] x:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_XBGR16161616	fourcc_code('X', 'B', '4', '8') /* [63:0] x:B:G:R 16:16:16:16 little endian */
> +
> +#define DRM_FORMAT_ARGB16161616	fourcc_code('A', 'R', '4', '8') /* [63:0] A:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_ABGR16161616	fourcc_code('A', 'B', '4', '8') /* [63:0] A:B:G:R 16:16:16:16 little endian */
> +
>  /*
>   * Floating point 64bpp RGB
>   * IEEE 754-2008 binary16 half-precision float
> @@ -155,6 +186,12 @@ extern "C" {
>  #define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0] A:R:G:B 16:16:16:16 little endian */
>  #define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0] A:B:G:R 16:16:16:16 little endian */
>  
> +/*
> + * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits
> + * of unused padding per component:
> + */
> +#define DRM_FORMAT_AXBXGXRX106106106106 fourcc_code('A', 'B', '1', '0') /* [63:0] A:x:B:x:G:x:R:x 10:6:10:6:10:6:10:6 little endian */
> +
>  /* packed YCbCr */
>  #define DRM_FORMAT_YUYV		fourcc_code('Y', 'U', 'Y', 'V') /* [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
>  #define DRM_FORMAT_YVYU		fourcc_code('Y', 'V', 'Y', 'U') /* [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
> @@ -320,7 +357,6 @@ extern "C" {
>   */
>  
>  /* Vendor Ids: */
> -#define DRM_FORMAT_MOD_NONE           0
>  #define DRM_FORMAT_MOD_VENDOR_NONE    0
>  #define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
>  #define DRM_FORMAT_MOD_VENDOR_AMD     0x02
> @@ -392,6 +428,16 @@ extern "C" {
>   */
>  #define DRM_FORMAT_MOD_LINEAR	fourcc_mod_code(NONE, 0)
>  
> +/*
> + * Deprecated: use DRM_FORMAT_MOD_LINEAR instead
> + *
> + * The "none" format modifier doesn't actually mean that the modifier is
> + * implicit, instead it means that the layout is linear. Whether modifiers are
> + * used is out-of-band information carried in an API-specific way (e.g. in a
> + * flag for drm_mode_fb_cmd2).
> + */
> +#define DRM_FORMAT_MOD_NONE	0
> +
>  /* Intel framebuffer modifiers */
>  
>  /*
> @@ -488,6 +534,25 @@ extern "C" {
>   */
>  #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
>  
> +/*
> + * Intel Color Control Surface with Clear Color (CCS) for Gen-12 render
> + * compression.
> + *
> + * The main surface is Y-tiled and is at plane index 0 whereas CCS is linear
> + * and at index 1. The clear color is stored at index 2, and the pitch should
> + * be ignored. The clear color structure is 256 bits. The first 128 bits
> + * represents Raw Clear Color Red, Green, Blue and Alpha color each represented
> + * by 32 bits. The raw clear color is consumed by the 3d engine and generates
> + * the converted clear color of size 64 bits. The first 32 bits store the Lower
> + * Converted Clear Color value and the next 32 bits store the Higher Converted
> + * Clear Color value when applicable. The Converted Clear Color values are
> + * consumed by the DE. The last 64 bits are used to store Color Discard Enable
> + * and Depth Clear Value Valid which are ignored by the DE. A CCS cache line
> + * corresponds to an area of 4x1 tiles in the main surface. The main surface
> + * pitch is required to be a multiple of 4 tile widths.
> + */
> +#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
> +
>  /*
>   * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
>   *
> @@ -997,9 +1062,9 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
>   * Not all combinations are valid, and different SoCs may support different
>   * combinations of layout and options.
>   */
> -#define __fourcc_mod_amlogic_layout_mask 0xf
> +#define __fourcc_mod_amlogic_layout_mask 0xff
>  #define __fourcc_mod_amlogic_options_shift 8
> -#define __fourcc_mod_amlogic_options_mask 0xf
> +#define __fourcc_mod_amlogic_options_mask 0xff
>  
>  #define DRM_FORMAT_MOD_AMLOGIC_FBC(__layout, __options) \
>  	fourcc_mod_code(AMLOGIC, \
> @@ -1195,4 +1260,3 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
>  #endif
>  
>  #endif /* DRM_FOURCC_H */
> -
> -- 
> 2.25.1
> 
> _______________________________________________
> igt-dev mailing list
> igt-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev


More information about the igt-dev mailing list