[PATCH] RFCv2: video support for dri2 (Rob Clark)

[Michel Dänzer]

On Fre, 2011-09-02 at 12:04 +0200, Christian König wrote: 
> 
> >  + flipping between multiple back buffers, perhaps not in order (to
> >    handle video formats with B-frames)
> Oh, yes please. The closed source drivers seems to do this also all the
> time, and I never really understood why DRI is limiting the buffers to
> the OGL attachment points.

Probably because DRI2 was designed mainly with GL direct rendering in
mind.


> > 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.
> If you ask me extending things seems the better way to do this.

Probably, though I'm not sure it's a good idea to extend existing DRI2
protocol requests. Even if it's theoretically possible, it'll probably
be much easier and less problematic to add new requests instead.


> > > Are you targeting/limiting this to a particular API (or the customary
> > > limitations of overlay HW)? I ask because VDPAU allows clients to pass
> > > in an arbitrary colour conversion matrix rather than color
> > > standard/hue/sat/bri/con, so it wouldn't be possible to use this in
> > > that context.
> > 
> > Ideally it would something that could be used either from
> > device-dependent VDPAU or VAAPI driver back-end, or something that
> > could be used in a generic way, for example GStreamer sink element
> > that could be used with software codecs.
> AFAIK DRI mostly isn't a device driver dependent protocol, and the
> client side doesn't necessary know to which hardware it is talking, just
> look at how gallium 3D is working, talking with X over the DRI protocol
> is part of the driver independent state tracker, and NOT part of the
> driver itself.
> 
> So having this driver independent is just a must have, and not optional.

Well, what's implemented in the Gallium DRI state tracker is just a de
facto standard which works with the current X drivers. The intention was
certainly for this to be opaque at the DRI2 protocol level. Once there
is divergence between how drivers handle this, the Gallium DRI state
tracker will probably need to grow some kind of driver specific hooks
for this.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer