vMeta GStreamer 1.0 plugins

[Daniel Drake]

On Thu, Aug 22, 2013 at 6:48 AM, Carlos Rafael Giani
<dv at pseudoterminal.org> wrote:
> First, I will paste from a chat I had in IRC with an X and Wayland
> developer:
>
> <dv_> are you familiar with xvideo together with xshm?
> <dv_> if not, who could know about internals?
> <daniels> hi, sure
> <daniels> what about it?
> <dv_> the problem is that there seems to be no guarantee that xvshmputimage
> actually finished drawing the frame internally when it returns
> <dv_> causing this bug: http://dev.laptop.org/ticket/12644#comment:7
> <dv_> I have experienced a related problem. my decoder sends the frame to
> xv, where it is drawn, and xvshmputimage apparently returns too soon. so,
> frame buffers that havent been fully read yet by the driver are filled with
> new data
> <daniels> yeah, there's a 'completion' event for that, analogous to
> wl_buffer::release
> <dv_> I tried that one, didnt help
> <dv_> is there a known issue with this?
> <daniels> oh
> <daniels> no, your driver's buggy then, if it sends a completion before it's
> finished using the frame
> <dv_> okay
> <daniels> tbf, the server does always send a shm completion event
> _immediately_ after XvdiPutImage returns, and there's no facility for doing
> otherwise
> <daniels> so if your driver does anything other than copy the data out
> immediately (e.g. schedules a draw using that area), then it's going to be
> buggy
> <dv_> this could very well be
> <dv_> because the hack that was added to it uses (actually abuses) the shm
> buffers as carriers for physical addresses
> <dv_> that is, instead of copying pixel data, it writes a 32bit-address into
> it, plus a magic number
> <dv_> the driver sees that magic number, knows that the next 4 bytes arent
> pixels but a physical address, and draws the pixels from that address
> <daniels> hah, right
> <daniels> yeah, you'd need to add new server <-> driver api for delayed
> completions
> <dv_> so I guess either I have to block XvdiPutImage until the hardware has
> drawn it fully,
> <dv_> or add something extra, yes
> <dv_> to add credence to that theory, I put an usleep call right after
> xvshmputimage(). 10ms. the flickering disappeared.
> <daniels> haw
> <daniels> oh yeah, and with the second-last para, what you'll be seeing
> there is the ReputImage hook, i suspect
> <daniels> if the window isn't yet visible, it'll just bin all the drawing
> requests
> <daniels> but when it comes with a non-zero clip, suddenly it'll just fire
> requests at the driver's ReputImage hook

That is interesting, nice to have some expert input backing up my
findings on #12644.

> So I looked into the dove driver in the kernel, and I see nothing to cause
> the driver to wait for the hardware to finish the drawing. I tried adding a
> vsync wait, but that did not help. (Or perhaps I put it in the wrong place?)

Maybe you have overtaken me in your understanding here, but from the
above conversation, I can't see how this is related to the kernel
driver. Instead we face these problems:

1. The X client cannot assume that the image has been drawn by the X
driver after XvShmPutImage(). It might be drawn some time later.
2. The X client cannot assume that the image has been drawn by the X
driver after XvShmPutImage(). It might never be drawn at all.
3. There is no alternative way of communicating that required
information from the X driver to the X client (unless we implement
something).

So as far as I understand, this communication problem sits between the
X client and DDX, not related to the kernel, and there is nothing that
the DDX can immediately do about it ("tbf, the server does always send
a shm completion event _immediately_ after XvdiPutImage returns, and
there's no facility for doing otherwise")

> John Nettleton then told me they don't have this issue because the OLPCs use
> the GPU for drawing, so the driver will use the texturedoverlay path. I
> cannot use the
> GPU mode, since then, symbols are missing (gcoHAL_QuerySeparated3D2D).

We definitely do have the issue described at #12644 and clarified by
daniels. I did work around it in a way that will result in occasional
bad frames being drawn ("flickering?") but we have not seen that so
far with gstreamer-0.10. If that problem is avoided due to using
textured overlays, I am not sure why, but it may be so.

I will try to run your code in the next few days and see if we do see
the flicker issue.

Note that we work with two versions of libgalcore, one for each
version of our hardware. The XO-1.75 version that runs against an
older version of libgalcore does not use that symbol. You can find it
in the xo-1.75 branch of
http://dev.laptop.org/git/projects/xf86-video-dove/

Daniel