video support for dri2 dri2video
authorRob Clark <rob@ti.com>
Tue, 15 Nov 2011 19:50:41 +0000 (13:50 -0600)
committerRob Clark <rob@ti.com>
Tue, 15 Nov 2011 19:50:41 +0000 (13:50 -0600)
commit5e832833f9382b84b29d87e6d4ac2ec19040ea4d
tree05cf75cca953817d63386c73a82d309d39b44cdd
parentfb4aed679e9dc75ebbcef33ef0eb0e25b39280bc
video support for dri2

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
v4: add header file changes

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.h
dri2proto.txt
dri2tokens.h