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. On Wed, Jul 20, 2011 at 3:15 PM, Rob Clark <[email protected]> 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 > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <[email protected]> _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
