Hi, 2014-03-14 22:52 GMT+01:00 Daniel Vetter <daniel@xxxxxxxx>: > 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@xxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
