summaryrefslogtreecommitdiff
path: root/include/uapi/drm/drm_fourcc.h
AgeCommit message (Collapse)Author
2026-02-14drm/fourcc: fix plane order for 10/12/16-bit YCbCr formatsSimon Ser
The short comments had the correct order, but the long comments had the planes reversed. Fixes: 2271e0a20ef7 ("drm: drm_fourcc: add 10/12/16bit software decoder YCbCr formats") Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Robert Mader <robert.mader@collabora.com> Link: https://patch.msgid.link/20260208224718.57199-1-contact@emersion.fr
2025-11-06drm: define NVIDIA DRM format modifiers for GB20xJames Jones
The layout of bits within the individual tiles (referred to as sectors in the DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() macro) changed for 8 and 16-bit surfaces starting in Blackwell 2 GPUs (With the exception of GB10). To denote the difference, extend the sector field in the parametric format modifier definition used to generate modifier values for NVIDIA hardware. Without this change, it would be impossible to differentiate the two layouts based on modifiers, and as a result software could attempt to share surfaces directly between pre-GB20x and GB20x cards, resulting in corruption when the surface was accessed on one of the GPUs after being populated with content by the other. Of note: This change causes the DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() macro to evaluate its "s" parameter twice, with the side effects that entails. I surveyed all usage of the modifier in the kernel and Mesa code, and that does not appear to be problematic in any current usage, but I thought it was worth calling out. Fixes: 6cc6e08d4542 ("drm/nouveau/kms: add support for GB20x") Signed-off-by: James Jones <jajones@nvidia.com> Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251030181153.1208-2-jajones@nvidia.com
2025-06-28drm/fourcc: Add RGB161616 and BGR161616 formatsJacopo Mondi
Add FourCC definitions for the 48-bit RGB/BGR formats to the DRM/KMS uapi. The format will be used by the Raspberry Pi PiSP Back End, supported by a V4L2 driver in kernel space and by libcamera in userspace, which uses the DRM FourCC identifiers. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Simon Ser <contact@emersion.fr> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Link: https://lore.kernel.org/r/20240226132544.82817-1-jacopo.mondi@ideasonboard.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-06-27drm/fourcc: Add 32b float formatsRob Clark
Add 1, 2, 3, and 4 component 32b float formats, so that buffers with these formats can be imported/exported with fourcc+modifier, and/or created by gbm. These correspond to PIPE_FORMAT_{R32,R32G32,R32G32B32,R32G32B32A32}_FLOAT in mesa. v2: Fix comment describing float32 layout [Sima] Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Simona Vetter <simona@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> Link: https://lore.kernel.org/r/20250625173712.116446-3-robin.clark@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-06-27drm/fourcc: Add missing half-float formatsRob Clark
Not something that is likely to be scanned out, but GPUs usually support half-float formats with 1, 2, or possibly 3 components, and it is useful to be able to import/export them with a valid fourcc, and/or use gbm to create them. These correspond to PIPE_FORMAT_{R16,R16G16,R16G16B16}_FLOAT in mesa. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Simona Vetter <simona@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> Link: https://lore.kernel.org/r/20250625173712.116446-2-robin.clark@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-05-29drm: drm_fourcc: add 10/12/16bit software decoder YCbCr formatsRobert Mader
This adds FOURCCs for 3-plane 10/12/16bit YCbCr formats used by software decoders like ffmpeg, dav1d and libvpx. The intended use-case is buffer sharing between decoders and GPUs by allocating buffers with e.g. udmabuf or dma-heaps, avoiding unnecessary copies and format conversions in various scenarios. Unlike formats typically used by hardware decoders the 10/12bit formats use a LSB alignment. In order to allow fast implementations in GL and Vulkan the padding must contain only zeros, so the float representation can be calculated by multiplying with 2^6=64 or 2^4=16 respectively. MRs or branches for Mesa, Vulkan, Gstreamer, Weston and Mutter can be found at: - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34303 - https://github.com/rmader/Vulkan-Docs/commits/ycbcr-16bit-lsb-formats/ - https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8540 - https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1753 - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4348 The naming scheme follows the 'P' and 'Q' formats. The 'S' stands for 'software' and was selected in order to make remembering easy. The 'Sx16' formats could as well be 'Qx16'. We stick with 'S' as 16bit software decoders are likely much more common than hardware ones for the foreseeable future. Note that these formats already have Vulkan equivalents: - VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM - VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM - VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM Signed-off-by: Robert Mader <robert.mader@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://lore.kernel.org/r/20250509133535.60330-1-robert.mader@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2025-03-14drm: add modifiers for Apple GPU layoutsAlyssa Rosenzweig
Apple GPUs support non-linear "GPU-tiled" image layouts. Add modifiers for these layouts. Mesa requires these modifiers to share non-linear buffers across processes, but no other userspace or kernel support is required/expected. These layouts are notably not used for interchange across hardware blocks (e.g. with the display controller). There are other layouts for that but we don't support them either in userspace or kernelspace yet (even downstream), so we don't add modifiers here. Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com> Reviewed-by: Sven Peter <sven@svenpeter.dev> Link: https://patchwork.freedesktop.org/patch/msgid/20250310-apple-twiddled-modifiers-v4-1-1ccac9544808@rosenzweig.io Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2025-01-24drm: add modifiers for MediaTek tiled formatsEric R. Smith
MediaTek (MTK) uses some unique tiled memory formats for video decoding. Add these to the uapi drm_fourcc.h so that we can use them in Mesa, GStreamer, and other tools/libraries. v2: - Classify the modifier bits into categories and provide room for expansion (Daniel S.) Signed-off-by: Eric R. Smith <eric.smith@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241219174929.126205-1-eric.smith@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2024-11-11drm/fourcc: add AMD_FMT_MOD_TILE_GFX9_4K_D_XQiang Yu
This is used when radeonsi export small texture's modifier to user with eglExportDMABUFImageQueryMESA(). mesa changes is available here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31658 Reviewed-by: Marek Olšák <marek.olsak@amd.com> Signed-off-by: Qiang Yu <qiang.yu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-08-21drm/fourcc: define Intel Xe2 related tile4 ccs modifiersJuha-Pekka Heikkila
Add Tile4 type ccs modifiers to indicate presence of compression on Xe2. Here is defined I915_FORMAT_MOD_4_TILED_LNL_CCS which is meant for integrated graphics with igpu related limitations Here is also defined I915_FORMAT_MOD_4_TILED_BMG_CCS which is meant for discrete graphics with dgpu related limitations Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240816115229.531671-3-juhapekka.heikkila@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-07-01drm/amdgpu: handle gfx12 in amdgpu_display_verify_sizesMarek Olšák
It verified GFX9-11 swizzle modes on GFX12, which has undefined behavior. Signed-off-by: Marek Olšák <marek.olsak@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-07-01drm/amdgpu: remove AMD_FMT_MOD_GFX12_DCC_MAX_COMPRESSED_BLOCK_* definitionsMarek Olšák
They were added accidentally. Signed-off-by: Marek Olšák <marek.olsak@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-26drm/amd: GFX12 changes for converting tiling flags to modifiersAurabindo Pillai
GFX12 swizzle mode and GCC formats changed and is much simpler. Use a seperate function for the same. Changes: * Swizzle mode is now 3 bits only * DCC enablement doesn't come from tiling_flags, it is always set in modifiers * DCC max compressed block size of 128B Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-04-26drm/amd: Add gfx12 swizzle mode defsAurabindo Pillai
Add GFX12 swizzle mode definitions for use with DCN401 Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-12-13drm/fourcc: fix spelling/typosRandy Dunlap
Correct spelling mistakes that were identified by codespell. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231213043925.13852-1-rdunlap@infradead.org
2023-10-24drm/fourcc: Add NV20 and NV30 YUV formatsJonas Karlman
DRM_FORMAT_NV20 and DRM_FORMAT_NV30 formats is the 2x1 and non-subsampled variant of NV15, a 10-bit 2-plane YUV format that has no padding between components. Instead, luminance and chrominance samples are grouped into 4s so that each group is packed into an integer number of bytes: YYYY = UVUV = 4 * 10 bits = 40 bits = 5 bytes The '20' and '30' suffix refers to the optimum effective bits per pixel which is achieved when the total number of luminance samples is a multiple of 4. V2: Added NV30 format Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Sandy Huang <hjc@rock-chips.com> Reviewed-by: Christopher Obbard <chris.obbard@collabora.com> Tested-by: Christopher Obbard <chris.obbard@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231023173718.188102-2-jonas@kwiboo.se
2023-05-15drm/fourcc: define Intel Meteorlake related ccs modifiersJuha-Pekka Heikkila
Add Tile4 type ccs modifiers with aux buffer needed for MTL Bspec: 49251, 49252, 49253 Cc: dri-devel@lists.freedesktop.org Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230514184240.6184-1-juhapekka.heikkila@gmail.com
2023-01-05drm/fourcc: Document open source user waiverDaniel Vetter
It's a bit a FAQ, and we really can't claim to be the authoritative source for allocating these numbers used in many standard extensions if we tell closed source or vendor stacks in general to go away. Iirc this was already clarified in some vulkan discussions, but I can't find that anywhere anymore. At least not in a public link. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Neil Trevett <ntrevett@nvidia.com> Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Maxime Ripard <maxime@cerno.tech> Acked-by: David Airlie <airlied@gmail.com> Acked-by: Marek Olšák <maraeo@gmail.com> Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Acked-by: Jason Ekstrand <jason.ekstrand@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123192437.1065826-1-daniel.vetter@ffwll.ch
2022-10-06drm/fourcc: add Vivante tile status modifiersLucas Stach
The tile status modifiers can be combined with all of the usual color buffer modifiers. When they are present an additional plane is added to the surfaces to share the tile status buffer. The TS modifiers describe the interpretation of the tag bits in this buffer. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Guido Günther <agx@sigxcpu.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220909093000.3458413-1-l.stach@pengutronix.de
2022-07-18drm/fourcc: Add formats for packed YUV 4:4:4 AVUY and XVUY permutationsLaurent Pinchart
Add FourCCs for two missing permutations of the packed YUV 4:4:4 color components, namely AVUY and XVUY. These formats are needed by the NXP i.MX8 ISI. While the ISI is supported by a V4L2 device (corresponding formats have been submitted to V4L2), it is handled in userspace by libcamera, which uses DRM FourCCs for pixel formats. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220616185210.22018-1-laurent.pinchart@ideasonboard.com
2022-07-13Merge drm/drm-next into drm-misc-nextMaxime Ripard
I need to have some vc4 patches merged in -rc4, but drm-misc-next is only at -rc2 for now. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-07-12Merge tag 'amd-drm-next-5.20-2022-07-05' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.20-2022-07-05: amdgpu: - Various spelling and grammer fixes - Various eDP fixes - Various DMCUB fixes - VCN fixes - GMC 11 fixes - RAS fixes - TMZ support for GC 10.3.7 - GPUVM TLB flush fixes - SMU 13.0.x updates - DCN 3.2 Support - DCN 3.2.1 Support - MES updates - GFX11 modifiers support - USB-C fixes - MMHUB 3.0.1 support - SDMA 6.0 doorbell fixes - Initial devcoredump support - Enable high priority gfx queue on asics which support it - Enable GPU reset for SMU 13.0.4 - OLED display fixes - MPO fixes - DC frame size fixes - ASPM support for PCIE 7.4/7.6 - GPU reset support for SMU 13.0.0 - GFX11 updates - VCN JPEG fix - BACO support for SMU 13.0.7 - VCN instance handling fix - GFX8 GPUVM TLB flush fix - GPU reset rework - VCN 4.0.2 support - GTT size fixes - DP link training fixes - LSDMA 6.0.1 support - Various backlight fixes - Color encoding fixes - Backlight config cleanup - VCN 4.x unified queue cleanup amdkfd: - MMU notifier fixes - Updates for GC 10.3.6 and 10.3.7 - P2P DMA support using dma-buf - Add available memory IOCTL - SDMA 6.0.1 fix - MES fixes - HMM profiler support radeon: - License fix - Backlight config cleanup UAPI: - Add available memory IOCTL to amdkfd Proposed userspace: https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg75743.html - HMM profiler support for amdkfd Proposed userspace: https://lists.freedesktop.org/archives/amd-gfx/2022-June/080805.html Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220705212633.6037-1-alexander.deucher@amd.com
2022-07-09drm/fourcc: Add DRM_FORMAT_D[1248]Geert Uytterhoeven
As Rn covers single-channel formats with a direct relationship between channel value and brightness, and Cn can be any colors, there are currently no fourcc codes to describe single-channel formats with an inverse relationship between channel value and brightness. Introduce fourcc codes for a single-channel frame buffer format with two, four, sixteen, or 256 brightness ("darkness") levels, where there is an inverse relationship between channel value and brightness. As the number of bits per pixel may be less than eight, some of these formats rely on proper block handling for the calculation of bits per pixel and pitch. The fill order (the order in which multiple pixels are packed in a byte) is the same order as used for grayscale (2, 4, and 16 levels) images in the PNG specification, Version 1.2. This order is also the recommended and default order (FillOrder = 1) for bilevel and grayscale (16 levels) images in the TIFF 6.0 Specification, and is also used for monochrome images in the PBM file format, monochrome Linux frame buffer logos, and BDF and PSF (Linux kernel) font files. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/6119f3abeda9baaa88652843960adc032da276b4.1657294931.git.geert@linux-m68k.org
2022-07-09drm/fourcc: Add DRM_FORMAT_R[124]Geert Uytterhoeven
Introduce fourcc codes for single-channel frame buffer formats with two, four, and sixteen brightness levels, where there is a direct relationship between channel value and brightness. As the number of bits per pixel is less than eight, these rely on proper block handling for the calculation of bits per pixel and pitch. The fill order (the order in which multiple pixels are packed in a byte) is the same order as used for grayscale (2, 4, and 16 levels) images in the PNG specification, Version 1.2. This order is also the recommended and default order (FillOrder = 1) for bilevel and grayscale (16 levels) images in the TIFF 6.0 Specification, and is also used for monochrome images in the PBM file format, monochrome Linux frame buffer logos, and BDF and PSF (Linux kernel) font files. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/96561a88e53c59cac72e66642bf4c097aacefd18.1657294931.git.geert@linux-m68k.org
2022-07-09drm/fourcc: Clarify the meaning of single-channel "red"Geert Uytterhoeven
Traditionally, the first channel has been called the "red" channel, but the fourcc values for single-channel "red" formats can also be used for other single-channel formats with a direct relationship between channel value and brightness, like grayscale. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/31d1792f26707a7270347e9916b4103470d2b192.1657294931.git.geert@linux-m68k.org
2022-07-09drm/fourcc: Add DRM_FORMAT_C[124]Geert Uytterhoeven
Introduce fourcc codes for color-indexed frame buffer formats with two, four, and sixteen colors, and provide a mapping from bits per pixel and depth to fourcc codes. As the number of bits per pixel is less than eight, these rely on proper block handling for the calculation of bits per pixel and pitch. The fill order (the order in which multiple pixels are packed in a byte) is the same order as used for indexed-color (2, 4, and 16 colors) images in the PNG specification, Version 1.2. This order is also the recommended and default order (FillOrder = 1) for palette-color (16 colors) images in the TIFF 6.0 Specification, and is also used for 16-color Linux frame buffer logos. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/3d88ca7ad32ff3ff3469c10f0b36c312ea233a33.1657294931.git.geert@linux-m68k.org
2022-06-28drm/fourcc: Document the Intel CCS modifiers' CC plane expected pitchImre Deak
The driver expects the pitch of the Intel CCS CC color planes to be 64 bytes aligned, adjust the modifier descriptions accordingly. Cc: Nanley Chery <nanley.g.chery@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Nanley Chery <nanley.g.chery@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220623144955.2486736-1-imre.deak@intel.com
2022-06-23drm/fourcc: fix integer type usage in uapi headerCarlos Llamas
Kernel uapi headers are supposed to use __[us]{8,16,32,64} types defined by <linux/types.h> as opposed to 'uint32_t' and similar. See [1] for the relevant discussion about this topic. In this particular case, the usage of 'uint64_t' escaped headers_check as these macros are not being called here. However, the following program triggers a compilation error: #include <drm/drm_fourcc.h> int main() { unsigned long x = AMD_FMT_MOD_CLEAR(RB); return 0; } gcc error: drm.c:5:27: error: ‘uint64_t’ undeclared (first use in this function) 5 | unsigned long x = AMD_FMT_MOD_CLEAR(RB); | ^~~~~~~~~~~~~~~~~ This patch changes AMD_FMT_MOD_{SET,CLEAR} macros to use the correct integer types, which fixes the above issue. [1] https://lkml.org/lkml/2019/6/5/18 Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.") Signed-off-by: Carlos Llamas <cmllamas@google.com> Reviewed-by: Simon Ser <contact@emersion.fr> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-06-03drm/amd: Add GFX11 modifiers support to AMDGPU (v3)Aurabindo Pillai
GFX11 IP introduces new tiling mode. Various combinations of DCC settings are possible and the most preferred settings must be exposed for optimal use of the hardware. add_gfx11_modifiers() is based on recommendation from Marek for the preferred tiling modifier that are most efficient for the hardware. v2: microtiling fix noticed by Marek v3: keep Z tiling check Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-05-11Merge tag 'drm-msm-next-2022-05-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/msm into drm-next - Fourcc modifier for tiled but not compressed layouts - Support for userspace allocated IOVA (GPU virtual address) - Devfreq clamp_to_idle fix - DPU: DSC (Display Stream Compression) support - DPU: inline rotation support on SC7280 - DPU: update DP timings to follow vendor recommendations - DP, DPU: add support for wide bus (on newer chipsets) - DP: eDP support - Merge DPU1 and MDP5 MDSS driver, make dpu/mdp device the master component - MDSS: optionally reset the IP block at the bootup to drop bootloader state - Properly register and unregister internal bridges in the DRM framework - Complete DPU IRQ cleanup - DP: conversion to use drm_bridge and drm_bridge_connector - eDP: drop old eDP parts again - DPU: writeback support - Misc small fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvJCr_1D8d0dgmyQC5HD4gmXeZw=bFV_CNCfceZbpMxRw@mail.gmail.com
2022-04-21drm/fourcc: Add QCOM tiled modifiersRob Clark
These are mainly used internally in mesa, although I believe the display should be able to scan out the TILED3 format. Currently we define this modifier internally in mesa for use with modifier based allocation. But we can get rid of that hack if we define the modfiers properly. Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20210904170603.1739137-1-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2022-04-12drm/fourcc: Introduce format modifier for DG2 clear colorMika Kahola
DG2 clear color render compression uses Tile4 layout. Therefore, we need to define a new format modifier for uAPI to support clear color rendering. v2: Display version is fixed. [Imre] KDoc is enhanced for cc modifier. [Nanley & Lionel] v3: Split out the modifier addition to a separate patch. Clarify the modifier layout description. Cc: dri-devel@lists.freedesktop.org Signed-off-by: Mika Kahola <mika.kahola@intel.com> cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Nanley Chery <nanley.g.chery@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220411143405.1073845-4-imre.deak@intel.com
2022-04-12drm/fourcc: Introduce format modifiers for DG2 render and media compressionMatt Roper
The render/media engines on DG2 unify render compression and media compression into a single format for the first time, using the Tile 4 layout for main surfaces. The compression algorithm is different from any previous platform and the display engine must still be configured to decompress either a render or media compressed surface; as such, we need new RC and MC framebuffer modifiers to represent buffers in this format. v2: Clarify modifier layout description. Cc: dri-devel@lists.freedesktop.org Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Nanley Chery <nanley.g.chery@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220411143405.1073845-2-imre.deak@intel.com
2022-02-24drm/i915: Introduce new Tile 4 formatStanislav Lisovskiy
This tiling layout uses 4KB tiles in a row-major layout. It has the same shape as Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x 4). It only differs from Tile Y at the 256B granularity in between. At this granularity, Tile Y has a shape of 16B x 32 rows, but this tiling has a shape of 64B x 8 rows. Reviewed-by: Imre Deak <imre.deak@intel.com> Acked-by: Nanley Chery <nanley.g.chery@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220118115544.15116-2-stanislav.lisovskiy@intel.com
2021-12-16drm/fourcc: Add packed 10bit YUV 4:2:0 formatDave Stevenson
Adds a format that is 3 10bit YUV 4:2:0 samples packed into a 32bit word (with 2 spare bits). Supported on Broadcom BCM2711 chips. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20211215091739.135042-2-maxime@cerno.tech
2021-10-28drm: Add R10 and R12 FourCCLaurent Pinchart
Add FourCCs for 10- and 12-bit red formats with padding to 16 bits. They correspond to the V4L2 10- and 12-bit greyscale (V4L2_PIX_FMT_Y10 and V4L2_PIX_FMT_Y12) formats, as well as the Bayer formats with the same bit depth (V4L2_PIX_FMT_SBGGR{10,12} and all other Bayer pattern permutations). These formats are not used by any kernel driver at this point, but need to be exposed to applications by libcamera, which uses DRM FourCCs for pixel formats. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211027233140.12268-1-laurent.pinchart@ideasonboard.com
2021-08-16drm/fourcc: Add macros to determine the modifier vendorThierry Reding
When working with framebuffer modifiers, it can be useful to extract the vendor identifier or check a modifier against a given vendor identifier. Add one macro that extracts the vendor identifier and a helper to check a modifier against a given vendor identifier. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210610111236.3814211-1-thierry.reding@gmail.com
2021-07-23drm/fourcc: Add modifier definitions for Arm Fixed Rate CompressionNormunds Rieksts
Arm Fixed Rate Compression (AFRC) is a proprietary fixed rate image compression protocol and format. It is designed to provide guaranteed bandwidth and memory footprint reductions in graphics and media use-cases. This patch aims to add modifier definitions for describing AFRC. Signed-off-by: Normunds Rieksts <normunds.rieksts@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210701170709.39922-1-normunds.rieksts@arm.com
2021-05-27drm/fourcc: Add 16 bpc fixed point framebuffer formats.Mario Kleiner
These are 16 bits per color channel unsigned normalized formats. They are supported by at least AMD display hw, and suitable for direct scanout of Vulkan swapchain images in the format VK_FORMAT_R16G16B16A16_UNORM. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-01-29Merge tag 'drm-intel-next-2021-01-27' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next - HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (Anshuman) - Fix DP vswing settings and handling (Imre, Ville) - Various display code clean-up (Jani, Ville) - Various display refactoring, including split out of pps, aux, and fdi (Ja\ ni, Dave) - Add DG1 missing workarounds (Jose) - Fix display color conversion (Chris, Ville) - Try to guess PCH type even without ISA bridge (Zhenyu) - More backlight refactor (Lyude) - Support two CSC module on gen11 and later (Lee) - Async flips for all ilk+ platforms (Ville) - Clear color support for TGL (RK) - Add a helper to read data from a GEM object page (Imre) - VRR/Adaptive Sync Enabling on DP/eDP for TGL+ (Manasi, Ville Aditya) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210127140822.GA711686@intel.com
2021-01-22drm/framebuffer: Format modifier for Intel Gen 12 render compression with ↵Radhakrishna Sripada
Clear Color Gen12 display can decompress surfaces compressed by render engine with Clear Color, add a new modifier as the driver needs to know the surface was compressed by render engine. V2: Description changes as suggested by Rafael. V3: Mention the Clear Color size of 64 bits in the comments(DK) v4: Fix trailing whitespaces v5: Explain Clear Color in the documentation. v6: Documentation Nitpicks(Nanley) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Kalyan Kondapally <kalyan.kondapally@intel.com> Cc: Rafael Antognolli <rafael.antognolli@intel.com> Cc: Nanley Chery <nanley.g.chery@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Nanley Chery <nanley.g.chery@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210114201314.783648-2-imre.deak@intel.com
2021-01-12drm/fourcc: fix Amlogic format modifier masksSimon Ser
The comment says the layout and options use 8 bits, and the shift uses 8 bits. However the mask is 0xf, ie. 0b00001111 (4 bits). This could be surprising when introducing new layouts or options that take more than 4 bits, as this would silently drop the high bits. Make the masks consistent with the comment and the shift. Found when writing a drm_info patch [1]. [1]: https://github.com/ascent12/drm_info/pull/67 Signed-off-by: Simon Ser <contact@emersion.fr> Fixes: d6528ec88309 ("drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression") Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210110125103.15447-1-contact@emersion.fr
2020-11-16drm/fourcc: fix AMD modifiers PACKERS field docSimon Ser
This field doesn't alias with BANK_XOR_BITS: PACKERS is bits 27:29 while BANK_XOR_BITS is bits 24:26. Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.") Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-11-13drm/fourcc: add table describing AMD modifiers bit layoutSimon Ser
The table describes how each bit in the u64 value is used. Explicitly state which values a field can take if we have defines for them. Also add a note when a field isn't always populated. Forcing people to update the table when changing the bit layout should make it more obvious when there's a mistake, I hope. If we get to the point where the bit layout gets more complicated, it might be worth it to split the table into multiple tables (e.g. one for GFX8, one for GFX9+, and so on). Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-11-13drm/fourcc: Fix modifier field mask for AMD modifiers.Bas Nieuwenhuizen
The DCC_MAX_COMPRESSED_BLOCK has to contain one of AMD_FMT_MOD_DCC_BLOCK_* and with 3 values this doesn't fit in 1 bit. Fix this cleanly while it is only in drm-next. Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-11-10Merge tag 'amd-drm-next-5.11-2020-11-05' of ↵Dave Airlie
git://people.freedesktop.org/~agd5f/linux into drm-next amd-drm-next-5.11-2020-11-05: amdgpu: - Add initial support for Vangogh - Add support for Green Sardine - Add initial support for Dimgrey Cavefish - Scatter/Gather display support for Renoir - Updates for Sienna Cichlid - Updates for Navy Flounder - SMU7 power improvements - Modifier support for gfx9+ - CI BACO fixes - Arcturus SMU fixes - Lots of code cleanups - DC fixes - Kernel doc fixes - Add more GPU HW client information to page fault error logging - MPO clock tuning for RV - FP fixes for DCN3 on ARM and PPC radeon: - Expose voltage via hwmon on Sumo APUs amdkfd: - Fix unique id handling - Misc fixes From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201105222749.201798-1-alexander.deucher@amd.com
2020-10-30drm/fourcc: Add AMD DRM modifiers.Bas Nieuwenhuizen
This adds modifiers for GFX9+ AMD GPUs. As the modifiers need a lot of parameters I split things out in getters and setters. - Advantage: simplifies the code a lot - Disadvantage: Makes it harder to check that you're setting all the required fields. The tiling modes seem to change every generation, but the structure of what each tiling mode is good for stays really similar. As such the core of the modifier is - the tiling mode - a version. Not explicitly a GPU generation, but splitting out a new set of tiling equations. Sometimes one or two tiling modes stay the same and for those we specify a canonical version. Then we have a bunch of parameters on how the compression works. Different HW units have different requirements for these and we actually have some conflicts here. e.g. the render backends need a specific alignment but the display unit only works with unaligned compression surfaces. To work around that we have a DCC_RETILE option where both an aligned and unaligned compression surface are allocated and a writer has to sync the aligned surface to the unaligned surface on handoff. Finally there are some GPU parameters that participate in the tiling equations. These are constant for each GPU on the rendering/texturing side. The display unit is very flexible however and supports all of them :| Some estimates: - Single GPU, render+texture: ~10 modifiers - All possible configs in a gen, display: ~1000 modifiers - Configs of actually existing GPUs in a gen: ~100 modifiers For formats with a single plane everything gets put in a separate DRM plane. However, this doesn't fit for some YUV formats, so if the format has >1 plane, we let the driver pack the surfaces into 1 DRM plane per format plane. This way we avoid X11 rendering onto the frontbuffer with DCC, but still fit into 4 DRM planes. Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-10-26drm: deprecate DRM_FORMAT_MOD_NONESimon Ser
DRM_FORMAT_MOD_NONE is in the list of vendors, which is pretty confusing. We already have DRM_FORMAT_MOD_VENDOR_NONE. Move it down in the list of format modifiers. DRM_FORMAT_MOD_NONE is an alias for DRM_FORMAT_MOD_LINEAR, however the name is confusing: NONE doesn't mean that the modifier is implicit, instead it means that the layout is linear. Deprecate it. Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/a2j8KTgc26k5QniSAhDSTgCw4XWZhmsNHwG8UVa6U@cp4-web-014.plabs.ch
2020-10-20drm/fourcc: Add AXBXGXRX106106106106 formatMatteo Franchin
Add ABGR format with 10-bit components packed in 64-bit per pixel. This format can be used to handle VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian architectures. Signed-off-by: Matteo Franchin <matteo.franchin@arm.com> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201012164043.23630-1-matteo.franchin@arm.com
2020-10-09drm/fourcc: document modifier uniqueness requirementsSimon Ser
There have suggestions to bake pitch alignment, address alignment, contiguous memory or other placement (hidden VRAM, GTT/BAR, etc) constraints into modifiers. Last time this was brought up it seemed like the consensus was to not allow this. Document this in drm_fourcc.h. There are several reasons for this. - Encoding all of these constraints in the modifiers would explode the search space pretty quickly (we only have 64 bits to work with). - Modifiers need to be unambiguous: a buffer can only have a single modifier. - Modifier users aren't expected to parse modifiers (except drivers). v2: add paragraph about aliases (Daniel) v3: fix unrelated changes sent with the patch v4: disambiguate users between driver and higher-level programs (Brian, Daniel) v5: fix AFBC example (Brian, Daniel) v6: remove duplicated paragraph (Daniel) Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: Dave Airlie <airlied@gmail.com> Cc: Marek Olšák <maraeo@gmail.com> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Michel Dänzer <michel@daenzer.net> Link: https://patchwork.freedesktop.org/patch/msgid/MGwgeXojKNdNXjCxuMhRlwcJM4vdYph_WJcMeGPPGMcRKtHV41XAXlh2tCc-pPJZCAhS3gwbWMWTd8f03NBA2ZYKfr0QxLhcPivpopr5c6M=@emersion.fr
generated by cgit v1.2.3 (git 2.46.0) at 2026-04-07 06:21:45 +0000