Occasional glitches with DMAbuf GL rendering (not offloading) with V4L2 decoders
This is something I have observed on two, maybe three, mostly independent driver stacks now (mostly as in: they both use Linux and Mesa): when using V4L2 decoders, there are sometimes frames with tearing - i.e. some part of the buffer looks like a different frame. I have only observed that when GTK was not offloading to the compositor but imported the buffer itself.
I haven't digged deeper into it yet, but my suspicion is:
- Unlike the Intel/AMD VA-API implementations, V4L2-dmabufs don't support implicit sync.
- So likely the affected buffers got released too early by GTK and are already getting recycled.
- The easiest explanation for that would be: GTK releases the buffers after submitting a frame / buffer swap and does not wait until GL has completed all operations.
Does this sound plausible, @matthiasc / @otte ? In that case this problem would fall into the general implicit vs explicit sync area.
I'm also not sure what would be the best solution here, but off-hand:
- Use the fancy new explicit sync protocol somehow (maybe a bit early).
- Somehow wait until the Wayland compositor signals that the EGL buffer is free to use again - difficult as we don't get to know the wl_buffer with EGL.
- Something more arbitrary/hacky. Like - wait either till the next frame or a 20ms timeout. To be replaced by something proper at some point.
- Some way to get a gl sync object?