[PATCH 1/1] [RFC] drm/fourcc: Add new unsigned R16_UINT/RG1616_UINT formats

[Dennis Tsiang]

Adds R16_UINT and RG1616_UINT DRM formats that represent unsigned
integer formats.

Although these formats are not used at this moment, they would need to
be exposed in the future for applications that need to use raw formats
suitable for camera ISPs

Signed-off-by: Dennis Tsiang <dennis.tsiang at arm.com>
Signed-off-by: Normunds Rieksts <normunds.rieksts at arm.com>
---
 include/uapi/drm/drm_fourcc.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index f1972154a594..fdb7d2a76507 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -112,14 +112,16 @@ extern "C" {

 /* 16 bpp Red */
 #define DRM_FORMAT_R16         fourcc_code('R', '1', '6', ' ') /* [15:0] R little endian */
+#define DRM_FORMAT_R16_UINT    fourcc_code('R', '1', '6', 'U') /* [15:0] R little endian, unsigned */

 /* 16 bpp RG */
 #define DRM_FORMAT_RG88                fourcc_code('R', 'G', '8', '8') /* [15:0] R:G 8:8 little endian */
 #define DRM_FORMAT_GR88                fourcc_code('G', 'R', '8', '8') /* [15:0] G:R 8:8 little endian */

 /* 32 bpp RG */
-#define DRM_FORMAT_RG1616      fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 16:16 little endian */
-#define DRM_FORMAT_GR1616      fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 16:16 little endian */
+#define DRM_FORMAT_RG1616              fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 16:16 little endian */
+#define DRM_FORMAT_RG1616_UINT         fourcc_code('R', 'G', '3', 'U') /* [31:0] R:G 16:16 little endian, unsigned */
+#define DRM_FORMAT_GR1616              fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 16:16 little endian */

 /* 8 bpp RGB */
 #define DRM_FORMAT_RGB332      fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 3:3:2 */
--
2.36.1




From: Dennis Tsiang
Sent: Monday, June 27, 2022 2:40 PM
To: dri-devel at lists.freedesktop.org <dri-devel at lists.freedesktop.org>
Cc: maarten.lankhorst at linux.intel.com <maarten.lankhorst at linux.intel.com>; mripard at kernel.org <mripard at kernel.org>; tzimmermann at suse.de <tzimmermann at suse.de>; airlied at linux.ie <airlied at linux.ie>; daniel at ffwll.ch <daniel at ffwll.ch>; sumit.semwal at linaro.org <sumit.semwal at linaro.org>; christian.koenig at amd.com <christian.koenig at amd.com>; linux-kernel at vger.kernel.org <linux-kernel at vger.kernel.org>; linux-media at vger.kernel.org <linux-media at vger.kernel.org>; linaro-mm-sig at lists.linaro.org <linaro-mm-sig at lists.linaro.org>; Liviu Dudau <Liviu.Dudau at arm.com>; Brian Starkey <Brian.Starkey at arm.com>; Lisa Wu <lisa.wu at arm.com>; Normunds Rieksts <Normunds.Rieksts at arm.com>; Dennis Tsiang <Dennis.Tsiang at arm.com>; nd <nd at arm.com>
Subject: [PATCH 0/1] [RFC] drm/fourcc: Add new unsigned R16_UINT/RG1616_UINT formats

This patch is an early RFC to discuss the viable options and
alternatives for inclusion of unsigned integer formats for the DRM API.

This patch adds a new single component 16-bit and a two component 32-bit
DRM fourcc’s that represent unsigned integer formats. The use case for
needing UINT formats, in our case, would be to support using raw buffers
for camera ISPs.

For images imported with DRM fourcc + modifier combination, the GPU
driver needs a way to determine the datatype of the format which
currently the DRM API does not provide explicitly with a notable
exception of the floating-point fourccs such as DRM_FORMAT_XRGB16161616F
as an example. As the DRM fourccs do not currently define the
interpretation of the data, should the information be made explicit in
the DRM API similarly to how it is already done in Vulkan?

The reason for introducing datatype to the DRM fourcc's is that the
alternative, for any API (e.g., EGL) that lacks the format datatype
information for fourcc/modifier combination for dma_buf interop would be
to introduce explicit additional metadata/attributes that encode this
information which then would be passed to the GPU driver but the
drawback of this is that it would require extending multiple graphics
APIs to support every single platform.

By having the DRM API expose the datatype information for formats saves
a lot of integration/verification work for all of the different graphics
APIs and platforms as this information could be determined by the DRM
triple alone for dma_buf interop.

It would be good to gather some opinions on what others think about
introducing datatypes to the DRM API.

Any feedback and suggestions are highly appreciated.

Dennis Tsiang (1):
  [RFC] drm/fourcc: Add new unsigned R16_UINT/RG1616_UINT formats

 include/uapi/drm/drm_fourcc.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--
2.36.1
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.