From: Rob Clark rob@ti.com
To allow the potential use of overlays to display video content, a few extra parameters are required:
+ source buffer in different format (for example, various YUV formats) and size as compared to destination drawable + multi-planar formats where discontiguous buffers are used for different planes. For example, luma and chroma split across multiple memory banks or with different tiled formats. + flipping between multiple back buffers, perhaps not in order (to handle video formats with B-frames) + cropping during swap.. in case of video, perhaps the required hw buffers are larger than the visible picture to account for codec borders (for example, reference frames where a block/macroblock moves past the edge of the visible picture, but back again in subsequent frames).
Current solutions use the GPU to do a scaled/colorconvert into a DRI2 buffer from the client context. The goal of this protocol change is to push the decision to use overlay or GPU blit to the xorg driver. --- Eventually this should replace Xv. With a few additions, like attributes, it could perhaps be possible to implement the client side Xv API on top of dri2.
Note: video is not exactly the same as 3d, there are a number of other things to consider (scaling, colorconvert, multi-planar formats). But on the other hand the principle is similar (direct rendering from hw video codecs). And a lot infrastructure of connection, authentication, is same. So there are two options, either extend DRI2 or add a new protocol which duplicates some parts. I'd like to consider extending DRI2 first, but if people think the requirements for video are too much different from 3d, then I could split this into a new protocol.
In either case, I will implement the xserver side infrastructure, but I wanted to get some feel for what is the preferred approach (extend dri2 or new videoproto) first.
dri2proto.txt | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 59 insertions(+), 1 deletions(-)
diff --git a/dri2proto.txt b/dri2proto.txt index df763c7..aa83b1a 100644 --- a/dri2proto.txt +++ b/dri2proto.txt @@ -163,7 +163,8 @@ and DRI2InvalidateBuffers. 6. Protocol Types
DRI2DRIVER { DRI2DriverDRI - DRI2DriverVDPAU } + DRI2DriverVDPAU, + DRI2DriverXV }
These values describe the type of driver the client will want to load. The server sends back the name of the driver to use @@ -184,6 +185,10 @@ DRI2ATTACHMENT { DRI2BufferFrontLeft These values describe various attachment points for DRI2 buffers.
+ In the case of video driver (DRI2DriverXV) the attachment, + other than DRI2BufferFrontLeft, just indicates buffer + number and has no other special significance. + DRI2BUFFER { attachment: CARD32 name: CARD32 pitch: CARD32 @@ -203,6 +208,16 @@ DRI2ATTACH_FORMAT { attachment: CARD32 format. 'attachment' describes the attachment point for the buffer, 'format' describes an opaque, device-dependent format for the buffer.
+ +DRI2ATTACH_VIDEO { attachment: CARD32 + format: CARD32, + width, height: CARD32 } + + The DRI2ATTACH_VIDEO describes an attachment and the associated + format for video buffers. 'attachment' describes the attachment + point for the buffer, 'format' describes a fourcc value for the + buffer. + ⚙ ⚙ ⚙ ⚙ ⚙ ⚙
@@ -367,6 +382,15 @@ The name of this extension is "DRI2". later.
┌─── + DRI2GetVideoBuffers + drawable: DRAWABLE + attachments: LISTofDRI2ATTACH_VIDEO + ▶ + width, height: CARD32 + buffers: LISTofDRI2BUFFER +└─── + +┌─── DRI2GetMSC drawable: DRAWABLE ▶ @@ -585,11 +609,21 @@ A.1 Common Types 4 CARD32 pitch 4 CARD32 cpp 4 CARD32 flags + 4 n extra names length + 4n LISTof extra names └─── A DRI2 buffer specifies the attachment, the kernel memory manager name, the pitch and chars per pixel for a buffer attached to a given drawable.
+ In case of multi-planar video formats, 'extra names' will give the + list of additional buffer names if there is one buffer per plane. + For example, I420 has one Y plane in with a 8bit luma value per + pixel, followed by one U plane subsampled 2x2 (with one 8bit U value + per 2x2 pixel block), followed by one V plane subsampled 2x2. This + could either be represented as a single buffer name, or three + separate buffer names, one each for Y, U, and V. + ┌─── DRI2ATTACH_FORMAT 4 CARD32 attachment @@ -599,6 +633,17 @@ A.1 Common Types This data type is only available with protocol version 1.1 or later.
+┌─── + DRI2ATTACH_VIDEO + 4 CARD32 attachment + 4 CARD32 format + 4 CARD32 width + 4 CARD32 height +└─── + Used to describe the attachment and format requested from the server. + This data type is only available with protocol version 1.? or + later. + A.2 Protocol Requests
┌─── @@ -745,6 +790,11 @@ A.2 Protocol Requests 4 CARD32 divisor_lo 4 CARD32 remainder_hi 4 CARD32 remainder_lo + 4 DRI2ATTACHMENT source + 4 CARD32 x1 + 4 CARD32 y1 + 4 CARD32 x2 + 4 CARD32 y2 ▶ 1 1 Reply 1 unused @@ -754,6 +804,14 @@ A.2 Protocol Requests 4 CARD32 swap_lo 5n LISTofDRI2BUFFER buffers └─── + The 'source', if not zero (DRI2BufferFrontLeft) indicates the + attachment point of the buffer to swap w/ DRI2BufferFrontLeft. + If zero is specified, DRI2BufferBackLeft is swapped with the + DRI2BufferFrontLeft buffer, for compatibility. + + If 'source' is not zero, (x1,y1), (x2,y2) specify the bounding + box in coordinates of the source buffer which should be scaled + to (0,0), (width,height) of the destination drawable.
┌─── DRI2GetMSC