On Wed, Jul 20, 2011 at 6:28 PM, Corbin Simpson <[email protected]> wrote: > 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 > > 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. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
