Tearing in embedded mode

[Plagman]

On DC at least, sometimes there's crazy tearing. We know we need to import a fence, so not too unexpected, but you'd think implicit sync would take care of it.

[Plagman]

Lots of tearing when the games are set to vsync = off. I think even if we dont' tie the internal cadence of the game's rendering to vblank when they have vsync = off, the output should not tear, so we're missing something to hold onto the game's buffer for as long as it's on screen maybe.

[emersion]

so we're missing something to hold onto the game's buffer for as long as it's on screen maybe.

Yes. wlroots will send a wl_buffer.release event as soon as the game submits a new buffer. Compositors that need to hold on to the buffer for longer need to reference the buffer with wlr_buffer_lock.

This should only cause issues with direct scan-out though. Composition should work fine without wlr_buffer_lock.

Will investigate.

[emersion]

This should only cause issues with direct scan-out though. Composition should work fine without wlr_buffer_lock.

Well, since threads are involved, scratch that.

[Plagman]

OK - usually direct scanout is the preferred path in embedded so that would be consistent with what you initially said. Sounds like we'll want to lock the buffer until we have a replacement already scanned out or composited in all cases, then.

Does locking the buffer feed back into the WSI interfaces of the application at the other end? Eg. if we lock a buffer and all the other ones are busy, will the app's SwapBuffers() or AcquireNextImage() block until we unlock it?

[emersion]

Does locking the buffer feed back into the WSI interfaces of the application at the other end? Eg. if we lock a buffer and all the other ones are busy, will the app's SwapBuffers() or AcquireNextImage() block until we unlock it?

Correct, clients can't start re-using the buffer before wl_buffer.release. See e.g. https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/egl/drivers/dri2/platform_wayland.c#L238

[Plagman]

Right now I can observe tearing for a few seconds after toggling off the overlay (in embedded mode with a SteamOS-style overlay, eg. gamescope -e -- steam -tenfoot -steamos). That makes us transition from scanning out our composited buffer to direct scanout, but unclear why tearing is only observed immediately after that. It stops after a second or two. If the game has vsync on, that doesn't seem to happen as much.