dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Gwenole Beauchesne <gb.devel@gmail.com>
Cc: mesa-dev@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: add FOURCC formats for compute dma_buf interop.
Date: Fri, 14 Mar 2014 22:52:44 +0100	[thread overview]
Message-ID: <20140314215244.GE30571@phenom.ffwll.local> (raw)
In-Reply-To: <1394819961-21537-1-git-send-email-gwenole.beauchesne@intel.com>

On Fri, Mar 14, 2014 at 06:59:21PM +0100, Gwenole Beauchesne wrote:
> This is a follow-up to:
> http://lists.freedesktop.org/archives/mesa-dev/2014-March/055742.html
> 
> Add formats meant to convey a "compute" dimension when a DRM fourcc
> format is needed for dma_buf interop (EGL, OpenCL).
> 
> Intended FOURCC format: ('T',<num_elements>,<type>,<size_element>).
> - <num_elements>: number of elements in the tuple. Range: [0..3].
> - <type>: type of each element. Values: {'_','I','U','F'},
>   respectively for normalized to [0..1] range, signed integers,
>   unsigned integers, floating-point.
> - <size_element>: size of the element. Values: {1, 2, 4, 8}.
> 
> All entities are represented in native-endian byte-order in memory.
> For example, 'T2F4' format would represent the (float, float) tuple
> where elements are stored in little-endian byte-order on x86.
> 
> Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

So this fourcc stuff started out as pixel formats for the ADDFB2 ioctl,
i.e. stuff that can be displayed. Hence my first question: How can we
display these bastards here?

Next up: dma-buf has absolutely no intrinsic concept of the contents of a
buffer. It's a raw pile of bytes with a fixed length.

So given all this: Why do we need this in the kernel's header? It sounds
like purely a userspace business with no need at all the enshrine this
into kernel ABI headers. Note that e.g. the mesa import/export interface
have their own fourcc #defines for exactly this reason.
-Daniel

> ---
>  include/drm/drm_fourcc.h |   78 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 78 insertions(+)
> 
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 85facb0..26a2ca8 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -127,4 +127,82 @@
>  #define DRM_FORMAT_YUV444	fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */
>  #define DRM_FORMAT_YVU444	fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */
>  
> +/**
> + * \defgroup api_drm_tuples Compute formats (tuples)
> + *
> + * The following formats are not meant for display. Rather, they are
> + * meant to convey a "compute" dimension when a DRM fourcc format is
> + * needed for dma_buf interop (EGL, OpenCL).
> + *
> + * Intended FOURCC format: ('T',<num_elements>,<type>,<size_element>).
> + * - <num_elements>: number of elements in the tuple. Range: [0..3].
> + * - <type>: type of each element. Values: {'_','I','U','F'},
> + *   respectively for normalized to [0..1] range, signed integers,
> + *   unsigned integers, floating-point.
> + * - <size_element>: size of the element. Values: {1, 2, 4, 8}.
> + *
> + * All entities are represented in native-endian byte-order in memory.
> + * For example, 'T2F4' format would represent the (float, float) tuple
> + * where elements are stored in little-endian byte-order on x86.
> + *
> + * @{
> + */
> +
> +/** Type of a tuple element */
> +enum {
> +    DRM_FORMAT_TUPLE_TYPE_UNORM	= '_', /**< Unsigned integer value normalized to [0..1] range */
> +    DRM_FORMAT_TUPLE_TYPE_SINT	= 'I', /**< Signed integer value */
> +    DRM_FORMAT_TUPLE_TYPE_UINT	= 'U', /**< Unsigned integer value */
> +    DRM_FORMAT_TUPLE_TYPE_FLOAT	= 'F', /**< Floating-point value */
> +};
> +
> +/** Generates a FOURCC value for a tuple */
> +#define DRM_FORMAT_TUPLE(num_elements, type, size) \
> +    fourcc_code('T', '0'+(num_elements), DRM_FORMAT_TUPLE_TYPE_##type, '0'+(size))
> +
> +/** @name Unsigned integers normalized to [0..1] range */
> +/**@{*/
> +#define DRM_FORMAT_T1_1		DRM_FORMAT_TUPLE(1, UNORM, 1) /** (X), 8-bit integers normalized to [0..1] range */
> +#define DRM_FORMAT_T2_1		DRM_FORMAT_TUPLE(2, UNORM, 1) /** (X, Y), 8-bit integers normalized to [0..1] range */
> +#define DRM_FORMAT_T4_1		DRM_FORMAT_TUPLE(4, UNORM, 1) /** (X, Y, Z, W), 8-bit integers normalized to [0..1] range */
> +#define DRM_FORMAT_T1_2		DRM_FORMAT_TUPLE(1, UNORM, 2) /** (X), 16-bit integers normalized to [0..1] range */
> +#define DRM_FORMAT_T2_2		DRM_FORMAT_TUPLE(2, UNORM, 2) /** (X, Y), 16-bit integers normalized to [0..1] range */
> +#define DRM_FORMAT_T4_2		DRM_FORMAT_TUPLE(4, UNORM, 2) /** (X, Y, Z, W), 16-bit integers normalized to [0..1] range */
> +/**@}*/
> +
> +/** @name Signed integer values */
> +/**@{*/
> +#define DRM_FORMAT_T1I1		DRM_FORMAT_TUPLE(1, SINT, 1) /** (X), 8-bit signed integer */
> +#define DRM_FORMAT_T2I1		DRM_FORMAT_TUPLE(2, SINT, 1) /** (X, Y), 8-bit signed integer */
> +#define DRM_FORMAT_T4I1		DRM_FORMAT_TUPLE(4, SINT, 1) /** (X, Y, Z, W), 8-bit signed integer */
> +#define DRM_FORMAT_T1I2		DRM_FORMAT_TUPLE(1, SINT, 2) /** (X), 16-bit signed integer */
> +#define DRM_FORMAT_T2I2		DRM_FORMAT_TUPLE(2, SINT, 2) /** (X, Y), 16-bit signed integer */
> +#define DRM_FORMAT_T4I2		DRM_FORMAT_TUPLE(4, SINT, 2) /** (X, Y, Z, W), 16-bit signed integer */
> +#define DRM_FORMAT_T1I4		DRM_FORMAT_TUPLE(1, SINT, 4) /** (X), 32-bit signed integer */
> +#define DRM_FORMAT_T2I4		DRM_FORMAT_TUPLE(2, SINT, 4) /** (X, Y), 32-bit signed integer */
> +#define DRM_FORMAT_T4I4		DRM_FORMAT_TUPLE(4, SINT, 4) /** (X, Y, Z, W), 32-bit signed integer */
> +/**@}*/
> +
> +/** @name Unsigned integer values */
> +/**@{*/
> +#define DRM_FORMAT_T1U1		DRM_FORMAT_TUPLE(1, UINT, 1) /** (X), 8-bit unsigned integer */
> +#define DRM_FORMAT_T2U1		DRM_FORMAT_TUPLE(2, UINT, 1) /** (X, Y), 8-bit unsigned integer */
> +#define DRM_FORMAT_T4U1		DRM_FORMAT_TUPLE(4, UINT, 1) /** (X, Y, Z, W), 8-bit unsigned integer */
> +#define DRM_FORMAT_T1U2		DRM_FORMAT_TUPLE(1, UINT, 2) /** (X), 16-bit unsigned integer */
> +#define DRM_FORMAT_T2U2		DRM_FORMAT_TUPLE(2, UINT, 2) /** (X, Y), 16-bit unsigned integer */
> +#define DRM_FORMAT_T4U2		DRM_FORMAT_TUPLE(4, UINT, 2) /** (X, Y, Z, W), 16-bit unsigned integer */
> +#define DRM_FORMAT_T1U4		DRM_FORMAT_TUPLE(1, UINT, 4) /** (X), 32-bit unsigned integer */
> +#define DRM_FORMAT_T2U4		DRM_FORMAT_TUPLE(2, UINT, 4) /** (X, Y), 32-bit unsigned integer */
> +#define DRM_FORMAT_T4U4		DRM_FORMAT_TUPLE(4, UINT, 4) /** (X, Y, Z, W), 32-bit unsigned integer */
> +/**@}*/
> +
> +/** @name Floating-point values */
> +/**@{*/
> +#define DRM_FORMAT_T1F4		DRM_FORMAT_TUPLE(1, FLOAT, 4) /** (X), 32-bit floating-point */
> +#define DRM_FORMAT_T2F4		DRM_FORMAT_TUPLE(2, FLOAT, 4) /** (X, Y), 32-bit floating-point */
> +#define DRM_FORMAT_T4F4		DRM_FORMAT_TUPLE(4, FLOAT, 4) /** (X, Y, Z, W), 32-bit floating-point */
> +/**@}*/
> +
> +/**@}*/
> +
>  #endif /* DRM_FOURCC_H */
> -- 
> 1.7.9.5
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2014-03-14 21:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAEDM96guoV3x1TpV7Lo1SUL1MXPG9yOir9Kn9Of5Po9YsVn_=A@mail.gmail.com>
2014-03-14 17:59 ` [PATCH] drm: add FOURCC formats for compute dma_buf interop Gwenole Beauchesne
2014-03-14 21:52   ` Daniel Vetter [this message]
2014-03-15  4:41     ` Gwenole Beauchesne
2014-03-15 11:28       ` Daniel Vetter
2014-03-19  6:30         ` Gwenole Beauchesne
2014-03-19 10:31           ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140314215244.GE30571@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gb.devel@gmail.com \
    --cc=mesa-dev@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox