[PATCH dri2proto] RFCv3: video support for dri2
Rob Clark
rob.clark at linaro.org
Sun Sep 18 19:47:40 PDT 2011
From: Rob Clark <rob at 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.
In many cases, an overlay will avoid several passes through memory
(blit/scale/colorconvert to DRI back-buffer on client side, blit to
front and fake-front, and then whatever compositing is done by the
window manager). On the other hand, overlays can often be handled
directly by the scanout engine in the display hardware, with the GPU
switched off.
The disadvantages of overlays are that they are (usually) a limited
resource, sometimes with scaling constraints, and certainly with
limitations about transformational effects.
The goal of combining video and dri2 is to have the best of both worlds,
to have the flexibility of GPU blitting (ie. no limited number of video
ports, no constraint about transformational effects), while still having
the power consumption benefits of overlays (reduced memory bandwidth
usage and ability to shut off the GPU) when the UI is relatively
static other than the playing video.
And even when GPU blitting is used, DRI2DriverXV allows to save one or
two copies: (1) no need for maintainence of DRI2BufferFakeFrontLeft, and
(2) in case that a pointer swap is not possible for switching back and
front buffer (for example, Window redirected to a pixmap with extra
padding around edges for window decorations), the colorconvert/scale
blit can be combined with the copy to the front buffer.
See:
https://wiki.linaro.org/OfficeofCTO/MemoryManagement?action=AttachFile&do=get&target=linux-video.pdf
ChangeLog:
v1: initial version
v2: add attributes, remove DRI2GetVideoBuffers/DRI2ATTACH_VIDEO and
instead use attributes to specify unscaled width/height
v3: support for variable length attributes and CSC matrix
Note: I'm not entirely sure how to handle the wire representation of
float matrix for CSC. OTOH, since DRI2 is a local-only protocol, I'm
not sure if it is necessary to precisely define this. Thoughts?
---
dri2proto.txt | 140 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 138 insertions(+), 2 deletions(-)
diff --git a/dri2proto.txt b/dri2proto.txt
index df763c7..b1d2393 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,11 @@ 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. There is no
+ automatic maintenance of DRI2BufferFakeFrontLeft.
+
DRI2BUFFER { attachment: CARD32
name: CARD32
pitch: CARD32
@@ -201,7 +207,8 @@ DRI2ATTACH_FORMAT { attachment: CARD32
The DRI2ATTACH_FORMAT describes an attachment and the associated
format. 'attachment' describes the attachment point for the buffer,
- 'format' describes an opaque, device-dependent format for the buffer.
+ 'format' describes an opaque, device-dependent format for the buffer,
+ or a fourcc for non-device-dependent formats.
⚙ ⚙ ⚙ ⚙ ⚙ ⚙
@@ -440,6 +447,104 @@ The name of this extension is "DRI2".
DRI2SwapBuffers requests to swap at most once per interval frames,
which is useful useful for limiting the frame rate.
+┌───
+ DRI2SetAttribute
+ drawable: DRAWABLE
+ attribute: ATOM
+ size: CARD32
+ value: CARD32 bytes
+ ▶
+└───
+ Errors: Window, Match, Value
+
+ The DRI2SetAttribute request sets the value of a drawable attribute.
+ The drawable attribute is identified by the attribute atom. The
+ following strings are guaranteed to generate valid atoms using the
+ InternAtom request.
+
+ String Size Type
+ -----------------------------------------------------------------
+
+ "XV_ENCODING" 4 ENCODINGID
+ "XV_CSC_MATRIX" 48 4x3 matrix of floats
+ "XV_WIDTH" 4 [0..MAX_INT]
+ "XV_HEIGHT" 4 [0..MAX_INT]
+ "XV_OSD" 4 XID
+
+ If the given attribute doesn't match an attribute supported by the
+ drawable a Match error is generated. The supplied encoding
+ must be one of the encodings listed for the adaptor, otherwise an
+ Encoding error is generated.
+
+ The XV_CSC_MATRIX attribute is defined to match the VDPAU
+ VdpCSCMatrix:
+
+ : NOTE: I couldn't actually find a definition of VADisplayAttribCSCMatrix
+ : so I went with VdpCSCMatrix (which is hopefully the same?)
+
+ ┌ ┐ ┌ ┐ ┌ ┐
+ │ R │ │ m00 m01 m02 m03 │ │ Y │
+ │ G │ = │ m10 m11 m12 m13 │ * │ Cb │
+ │ B │ │ m20 m21 m22 m23 │ │ Cr │
+ └ ┘ └ ┘ │ 1.0 │
+ └ ┘
+
+ : TODO: do we need to define the binary float layout for protocol?
+ : Or is it enough that DRI2 is a local-only protocol, so we don't
+ : need to care about that?
+
+ If the adaptor doesn't support the specified CSC matrix, the closest
+ values supported are assumed. The DRI2GetAttribute request can be used
+ to query the resulting values.
+
+ The "XV_WIDTH" and "XV_HEIGHT" attributes default to zero, indicating
+ that no scaling is performed and the buffer sizes match the drawable
+ size. They can be overriden by the client if scaling is desired.
+
+ The "XV_OSD" attribute specifies the XID of a drawable containing
+ ARGB data to be non-destructively overlayed over the video. This
+ could be used to implement subtiles, on-screen-menus, etc. Note
+ that a DRI2DriverDRI driver could be connected to this drawable, to
+ enable GPU rendered OSD content, or alternatively normal indirect
+ X11 draw primitives can be used.
+
+┌───
+ DRI2GetAttribute
+ drawable: DRAWABLE
+ attribute: ATOM
+ ▶
+ size: CARD32
+ value: CARD32 bytes
+└───
+ Errors: Window, Match
+
+ The DRI2GetAttribute request returns the current value of the
+ attribute identified by the given atom. If the given atom
+ doesn't match an attribute supported by the adaptor a Match
+ error is generated.
+
+┌───
+ DRI2GetFormats
+ drawable: DRAWABLE
+ ▶
+ formats: LISTofCARD32
+└───
+ Errors: Window
+
+ Query the driver for supported formats, which can be used with
+ DRI2GetBuffersWithFormat. The 'format' describes an opaque,
+ device-dependent format for the buffer, or a fourcc for
+ non-device-dependent formats.
+
+ : NOTE: I'm trying to avoid re-inventing something along the lines of
+ : XvImageFormatValues, which I think is overly complex and still not
+ : sufficient to describe weird device-dependent or tiled formats. On
+ : the other hand, it is probably not necessary to perfectly describe
+ : weird device-dependent formats. Just use at least one non-ascii
+ : character so the value does not collide with valid fourcc's. I
+ : looked at intel and nouveau xorg driver code, and it doesn't seem
+ : that they use values that could be confused with fourcc values.
+
⚙ ⚙ ⚙ ⚙ ⚙ ⚙
9. Extension Events
@@ -585,11 +690,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
@@ -745,6 +860,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 +874,22 @@ 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.
+
+ NOTE: cropping could also be handled via attributes.. but it
+ gets a bit fuzzy when the crop can change frame-by-frame. We
+ could just decree "updated crop attributes apply on the next
+ SwapBuffers" but it is a bit hand-wavey..
+
+ : TODO: do I add another DRI2SwapBuffer's msg description, or is
+ : it ok to just append fields to the end of the Req part?
┌───
DRI2GetMSC
--
1.7.5.4
More information about the xorg-devel
mailing list