RFC: video with DRI2

[Younes Manton]

On Wed, Jul 20, 2011 at 6:28 PM, Corbin Simpson
<mostawesomedude at gmail.com> wrote:
> On Wed, Jul 20, 2011 at 3:15 PM, Rob Clark <robdclark at gmail.com> wrote:
>> All,
>>
>> I've been looking a bit at dri2 as a way to handle video display (in
>> addition to just GL stuff).  Basically it seems like a convenient way
>> to share buffer handles between Xorg driver and client video player
>> app.  (Yes, I know about Xv.. no, it isn't useful if I want to avoid a
>> memcpy.)
>>
>> The basic differences compared to some 3d/gl app:
>> 1) color format..  video content would (most likely) be in some YUV
>> format.  No problem for DRI2GetBuffersWithFormat, passing a fourcc as
>> the 'format' value seems sane.
>>
>> 2) attachment points.. for GL you might triple or double buffer.  For
>> video you might have >16 buffers.  This mostly seems ok, most of the
>> existing dri2.c code seems like it would tolerate me requesting
>> non-existing attachment points.  The one bit of awkwardness is that
>> DRI2SwapBuffers doesn't let me specify *which* buffers I want to swap.
>>  Maybe I could cope by playing some games by changing buffer name to
>> buffer object mappings.  The tricky thing to keep in mind is that in
>> the video case the buffers would be displayed in a seemingly random
>> (to the xorg driver) order, if B-frames are present..  decode order !=
>> display order
>>
>> 3) cropping.. in case you are actually trying to share buffers without
>> copy between video codec and Xorg, you probably have some codec edges
>> that need to be cropped out.  So you need some way to request buffers
>> larger than the target drawable, and specify some x,y offset into that
>> larger buffer to find what should appear on screen.  In some cases it
>> might even be that the x,y offset is changing frame by frame.
>>
>>
>> Some of these issues go away if you do a blit/colorconvert on client
>> side into the DRI2 buffer.  This seems to be what intel vaapi driver
>> (and probably others) are doing currently.  Although my ideal goal is
>> to push this to xorg side, and let xorg driver decide whether to blit,
>> or use an overlay, etc.
>>
>>
>> The approaches I can think of to deal with this are:
>> 1) add DRI2Get/SetProperty sort of messages.  Some things like
>> cropping offsets and perhaps actual requested buffers sizes could be
>> set as properties.  There are some things that are a bit iff'y about
>> this.  For example, changing crop should apply on the next
>> SwapBuffers.  The good news is it would be easy to later define new
>> properties as the need arises.
>>
>> 2) Add additional parameters to GetBuffers and SwapBuffers
>>
>> 3) Define some new msgs with extra parameters...
>> DRI2GetBufferWithFormatAndMore, etc.
>>
>>
>> Anyone have some opinions on the best approach to take?  Anyone else
>> given some thought to this sort of thing before?
>>
>>
>>
>> BR,
>> -R
>
> If I recall correctly, DRI2 can transport VDPAU and there is some
> libvdpau stuff in the Mesa/Gallium source tree. I haven't really been
> heavily involved, but I would imagine that that might be interesting
> to you.
>
> ~ C.
>

The code in mesa does everything client side since overlays are pretty
much extinct so doesn't really have a need for any of this, although
more control over the swap chain might be useful.