[PATCH dri3proto v2] Add modifier/multi-plane requests, bump to v1.1
Eric Anholt
eric at anholt.net
Tue Jul 25 21:20:42 UTC 2017
Daniel Stone <daniels at collabora.com> writes:
> DRI3 version 1.1 adds support for explicit format modifiers, including
> multi-planar buffers.
I still want proper 64-bit values, and I don't think the little XSync
mess will be much of a blocker.
> Signed-off-by: Daniel Stone <daniels at collabora.com>
> ---
> dri3proto.h | 142 ++++++++++++++++++++++++++-
> dri3proto.txt | 300 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 438 insertions(+), 4 deletions(-)
>
> Sorry, this was supposed to get sent out with the revised patchset.
>
> Now with actual descriptive text.
>
> diff --git a/dri3proto.h b/dri3proto.h
> index ceddee8..442b714 100644
> --- a/dri3proto.h
> +++ b/dri3proto.h
> @@ -25,7 +25,7 @@
>
> #define DRI3_NAME "DRI3"
> #define DRI3_MAJOR 1
> -#define DRI3_MINOR 0
> +#define DRI3_MINOR 1
>
> #define DRI3NumberErrors 0
> #define DRI3NumberEvents 0
> @@ -37,7 +37,15 @@
> #define X_DRI3FenceFromFD 4
> #define X_DRI3FDFromFence 5
>
> -#define DRI3NumberRequests 6
> +/* v1.1 */
> +#define xDRI3GetSupportedFormats 6
> +#define xDRI3GetSupportedModifiers 7
> +#define xDRI3PixmapFromBuffers 8
> +#define xDRI3BuffersFromPixmap 9
> +#define xDRI3FenceFromDMAFenceFD 10
> +#define xDRI3DMAFenceFDFromFrence 11
> +
> +#define DRI3NumberRequests 12
>
> typedef struct {
> CARD8 reqType;
> @@ -164,4 +172,134 @@ typedef struct {
>
> #define sz_xDRI3FDFromFenceReply 32
>
> +/* v1.1 */
> +
> +typedef struct {
> + CARD8 reqType;
> + CARD8 dri3ReqType;
> + CARD16 length B16;
> + CARD32 window B32;
> +} xDRI3GetSupportedFormatsReq;
> +#define sz_xDRI3GetSupportedFormatsReq 8
> +
> +typedef struct {
> + BYTE type; /* X_Reply */
> + CARD8 pad1;
> + CARD16 sequenceNumber B16;
> + CARD32 length B32;
> + CARD32 numFormats B32;
> + CARD32 pad12 B32;
> + CARD32 pad16 B32;
> + CARD32 pad20 B32;
> + CARD32 pad24 B32;
> + CARD32 pad28 B32;
> +} xDRI3GetSupportedFormatsReply;
> +#define sz_xDRI3GetSupportedFormatsReply 32
> +
> +typedef struct {
> + CARD8 reqType;
> + CARD8 dri3ReqType;
> + CARD16 length B16;
> + CARD32 window B32;
> + CARD32 format B32;
> +} xDRI3GetSupportedModifiersReq;
> +#define sz_xDRI3GetSupportedModifiersReq 12
> +
> +typedef struct {
> + BYTE type; /* X_Reply */
> + CARD8 pad1;
> + CARD16 sequenceNumber B16;
> + CARD32 length B32;
> + CARD32 format B32;
> + CARD32 numModifiers B32;
> + CARD32 pad16 B32;
> + CARD32 pad20 B32;
> + CARD32 pad24 B32;
> + CARD32 pad28 B32;
> +} xDRI3GetSupportedModifiersReply;
> +#define sz_xDRI3GetSupportedModifiersReply 32
> +
> +typedef struct {
> + CARD8 reqType;
> + CARD8 dri3ReqType;
> + CARD16 length B16;
> + CARD32 pixmap B32;
> + CARD32 drawable B32;
> + CARD8 num_buffers; /* Number of file descriptors passed */
> + CARD8 pad13;
> + CARD16 pad14 B16;
> + CARD16 width B16;
> + CARD16 height B16;
> + CARD32 stride0 B32;
> + CARD32 offset0 B32;
> + CARD32 stride1 B32;
> + CARD32 offset1 B32;
> + CARD32 stride2 B32;
> + CARD32 offset2 B32;
> + CARD32 stride3 B32;
> + CARD32 offset3 B32;
> + CARD32 format B32;
> + CARD32 modifier_hi B32;
> + CARD32 modifier_lo B32;
> +} xDRI3PixmapFromBuffersReq;
> +#define sz_xDRI3PixmapFromBuffersReq 64
> +
> +typedef struct {
> + CARD8 reqType;
> + CARD8 dri3ReqType;
> + CARD16 length B16;
> + CARD32 pixmap B32;
> +} xDRI3BuffersFromPixmapReq;
> +#define sz_xDRI3BuffersFromPixmapReq 8
> +
> +typedef struct {
> + BYTE type; /* X_Reply */
> + CARD8 nfd; /* Number of file descriptors returned */
> + CARD16 sequenceNumber B16;
> + CARD32 length B32;
> + CARD16 width B16;
> + CARD16 height B16;
> + CARD32 format B32;
> + CARD32 modifier_hi B32;
> + CARD32 modifier_lo B32;
> + CARD32 pad24 B32;
> + CARD32 pad28 B32;
> +} xDRI3BuffersFromPixmapReply;
> +#define sz_xDRI3BuffersFromPixmapReply 32
> +
> +typedef struct {
> + CARD8 reqType;
> + CARD8 dri3ReqType;
> + CARD16 length B16;
> + CARD32 drawable B32;
> + CARD32 fence B32;
> +} xDRI3FenceFromDMAFenceFDReq;
> +
> +#define sz_xDRI3FenceFromDMAFenceFDReq 12
> +
> +typedef struct {
> + CARD8 reqType;
> + CARD8 dri3ReqType;
> + CARD16 length B16;
> + CARD32 drawable B32;
> + CARD32 fence B32;
> +} xDRI3DMAFenceFDFromFenceReq;
> +
> +#define sz_xDRI3DMAFenceFDFromFenceReq 12
> +
> +typedef struct {
> + BYTE type; /* X_Reply */
> + CARD8 nfd; /* Number of file descriptors returned (1) */
> + CARD16 sequenceNumber B16;
> + CARD32 length B32;
> + CARD32 pad08 B32;
> + CARD32 pad12 B32;
> + CARD32 pad16 B32;
> + CARD32 pad20 B32;
> + CARD32 pad24 B32;
> + CARD32 pad28 B32;
> +} xDRI3DMAFenceFDFromFenceReply;
> +
> +#define sz_xDRI3DMAFenceFDFromFenceReply 32
> +
> #endif
> diff --git a/dri3proto.txt b/dri3proto.txt
> index dac11d3..e906419 100644
> --- a/dri3proto.txt
> +++ b/dri3proto.txt
> @@ -1,11 +1,12 @@
> The DRI3 Extension
> - Version 1.0
> - 2013-6-4
> + Version 1.1
> + 2017-06-27
>
> Keith Packard
> keithp at keithp.com
> Intel Corporation
>
> +
> 1. Introduction
>
> The DRI3 extension provides mechanisms to translate between direct
> @@ -27,6 +28,8 @@ Dave Airlie <airlied at redhat.com>
> Kristian Høgsberg <krh at bitplanet.net>
> James Jones <janomes at nvidia.com>
> Arthur Huillet <arthur.huillet at free.fr>
> +Louis-Francis Ratté-Boulianne <lfrb at collabora.com>
> +Daniel Stone <daniels at collabora.com>
>
> ❄ ❄ ❄ ❄ ❄ ❄ ❄
>
> @@ -199,6 +202,182 @@ The name of this extension is "DRI3"
> associated with a direct rendering device that 'fence' can
> work with, otherwise a Match error results.
>
> +┌───
> + DRI3GetSupportedFormats
> + window: WINDOW
> + ▶
> + num_formats: CARD32
> + formats: ListOfCARD32
> +└───
> + Errors: Window, Match
> +
> + For the Screen associated with 'window', return a list of
> + supported DRM FourCC formats, as defined in drm_fourcc.h,
> + supported as formats for DRI3 pixmap/buffer interchange.
> + The length of the list, in number of CARD32 elements,
> + is returned in 'num_formats'.
> +
> +┌───
> + DRI3GetSupportedModifiers
> + window: WINDOW
> + format: CARD32
> + ▶
> + num_modifiers: CARD32
> + modifiers: ListOfCARD32
> +└───
> + Errors: Window, Match
> +
> + For the Screen associated with 'window', return a list of
> + supported DRM FourCC modifiers, as defined in drm_fourcc.h,
> + supported as formats for DRI3 pixmap/buffer interchange.
> + Each modifier is returned as returned as a CARD32
> + containing the most significant 32 bits, followed by a
> + CARD32 containing the least significant 32 bits. The hi/lo
> + pattern repeats 'num_modifiers' times, thus there are
> + '2 * num_modifiers' CARD32 elements returned.
Should any meaning be assumed from the ordering of modifiers?
> +┌───
> + DRI3PixmapFromBuffers
> + pixmap: PIXMAP
> + drawable: DRAWABLE
> + num_buffers: CARD8
> + width, height: CARD16
> + stride0, offset0: CARD32
> + stride1, offset1: CARD32
> + stride2, offset2: CARD32
> + stride3, offset3: CARD32
> + format, modifier_hi, modifier_lo: CARD32
> + buffers: ListOfFD
> +└───
> + Errors: Alloc, Drawable, IDChoice, Value, Match
> +
> + Creates a pixmap for the direct rendering object associated
> + with 'buffers'. Changes to pixmap will be visible in that
> + direct rendered object and changes to the direct rendered
> + object will be visible in the pixmap.
> +
> + In contrast to PixmapFromBuffers, multiple buffers may be
I think you meant PixmapFromBuffer
> + combined to specify a single logical source for pixel
> + sampling: 'num_buffers' may be set from 1 (single buffer,
> + akin to PixmapFromBuffer) to 4. This is the number of file
> + descriptors which will be sent with this request; one per
> + buffer.
> +
> + The exact configuration of the buffer is specified by 'format',
> + a DRM FourCC format token as defined in that project's
> + drm_fourcc.h header, in combination with the modifier.
> +
> + Modifiers allow explicit specification of non-linear sources,
> + such as tiled or compressed buffers. 'modifier_hi' (the most
> + significant 32 bits of a 64-bit value) and 'modifier_lo' are
> + combined to produce a single DRM format modifier token, again
> + as defined in drm_fourcc.h. The combination of format and
> + modifier allows unambiguous declaration of the buffer layout
> + in a manner defined by the DRM tokens.
> +
> + DRM_FORMAT_MOD_INVALID may be passed for 'modifier', in which
> + case the driver may make its own inference as to the exact
> + layout of the buffer(s).
> +
> + 'width' and 'height' describe the geometry (in pixels) of the
> + logical pixel-sample source.
> +
> + 'strideN' and 'offsetN' define the number of bytes per logical
> + scanline, and the distance in bytes from the beginning of the
> + buffer passed for that plane until the start of the sample
> + source for that plane, respectively for plane N. If the plane
> + is not used according to the format and modifier specification,
> + both values for that plane must be zero.
> +
> + Precisely how any additional information about the buffer is
> + shared is outside the scope of this extension.
> +
> + If the buffer(s) cannot be used with the screen associated with
> + 'pixmap', a Match error is returned.
> +
> + If the format and modifier combination is not supported by the
> + screen, a Value error is returned.
Should we be specifying how the depth of the Pixmap is determined from
the fourcc? Should we be specifying if X11 rendering works on various
fourccs, and between pixmaps of different fourccs? It's not clear to me
what glamor would need to be able to do with these pixmaps (can I
CopyArea between XRGB888 and BGRX8888? What does that even mean?)
> +┌───
> + DRI3BuffersFromPixmap
> + pixmap: PIXMAP
> + ▶
> + nfd: CARD8
> + width, height: CARD16
> + format, modifier_hi, modifier_lo: CARD32
> + strides: ListOfCARD32
> + offsets: ListOfCARD32
> + buffers: ListOfFD
> +└───
> + Errors: Pixmap, Match
> +
> + Pass back direct rendering objects associated with 'pixmap'.
Maybe "Returns direct rendering objects..."
> + Changes to 'pixmap' will be visible in the direct rendered
> + objects and changes to the direct rendered objects will be
> + visible in 'pixmap' after flushing and synchronization.
> +
> + 'width' and 'height' describe the geometry (in pixels) of the
> + logical pixel-sample source from combining the direct rendering
> + objects.
> +
> + 'format' describes a DRM FourCC format token, with
> + 'modifier_hi' (most significant 32 bits) and 'modifier_lo'
> + (least significant 32 bits) being combined together to produce
> + a single unsigned 64-bit 'modifier' token. See
> + PixmapFromBuffers for more details on DRM format definitions.
> +
> + 'nfd' describes the number of buffers returned for the pixmap,
> + which must be combined together according to 'format' and
> + 'modifier'.
> +
> + For each buffer, there is an entry in the 'strides',
> + 'offsets', and 'buffers' list. 'buffer' contains a single file
> + descriptor referring to the buffer. 'stride' specifies the
> + number of bytes per logical scanline for this plane, and
> + 'offset' specifies the distance in bytes from the beginning
> + of 'buffer' until the start of the sample source for that
> + plane.
> +
> + Precisely how any additional information about the buffer is
> + shared is outside the scope of this extension.
> +
> + If buffers cannot be exported from the the screen associated
> + with 'pixmap', a Match error is returned.
> +
> +┌───
> + DRI3FenceFromDMAFenceFD
> + drawable: DRAWABLE
> + fence: FENCE
> + fd: FD
> +└───
> + Errors: IDChoice, Drawable
> +
> + Creates a Sync extension Fence that provides the regular Sync
> + extension semantics. The Fence will begin untriggered, and
> + become triggered when the underlying dma-fence FD signals.
> + The resulting Sync Fence is a one-shot, and may not be
> + manually triggered, reset, or reused until it is destroyed.
> + Details about the mechanism used with this file descriptor are
> + outside the scope of the DRI3 extension.
I was surprised to find this lumped in with a commit about
multi-planar/buffer support -- is it actually related, and is it used?
Must an implementation supporting 1.1 support this? dma-fences seem
like a pretty recent kernel feature.
> +┌───
> + DRI3DMAFenceFDFromFence
> + drawable: DRAWABLE
> + fence: FENCE
> + ▶
> + fd: FD
> +└───
> + Errors: IDChoice, Drawable, Match
> +
> + Given a Sync extension Fence originally created by the
> + DRI3FenceFromDMAFenceFD request, return the underlying
> + dma-fence FD to the client. Details about the mechanism used
> + with this file descriptor are outside the scope of the DRI3
> + extension. 'drawable' must be associated with a direct
> + rendering device that 'fence' can work with, otherwise a Match
> + error results. NB: it is quite likely this will be forever
> + unused, and may be removed in later revisions.
> +
Let's not introduce protocol if we can't come up with a use for it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170725/a2a6c6dc/attachment.sig>
More information about the xorg-devel
mailing list