[Mesa-dev] [PATCH] drm: add FOURCC formats for compute dma_buf interop.

Fri Mar 14 21:41:05 PDT 2014

Hi,

2014-03-14 22:52 GMT+01:00 Daniel Vetter <daniel at ffwll.ch>:
> 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 at 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?

It's not meant to be displayed. The idea was maybe we could detect the
fourcc (e.g. (fourcc & 0xff) == 'T') and reject the buffer accordingly
when submitted to one of the display ioctl?

> 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.

I could have stuffed everything in gbm.h for instance, or another new
header, but the EXT_dma_buf_import extension actually mentions
drm_fourcc.h. So, that's why I finally moved the definitions to there.
:)

What would be the better place? Can we make the userspace libdrm
version of the file live totally unsynchronized from the kernel
headers then?

Thanks,
Gwenole.

>>  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 at 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