Thomas Zimmermann <tzimmermann@xxxxxxx> writes:
Hi Javier
Am 09.11.23 um 18:24 schrieb Javier Martinez Canillas:
Hello,
This series is to fix an issue that surfaced after damage clipping was
enabled for the virtio-gpu by commit 01f05940a9a7 ("drm/virtio: Enable
fb damage clips property for the primary plane").
After that change, flickering artifacts was reported to be present with
both weston and wlroots wayland compositors when running in a virtual
machine. The cause was identified by Sima Vetter, who pointed out that
virtio-gpu does per-buffer uploads and for this reason it needs to do
a buffer damage handling, instead of frame damage handling.
I'm having problem understanding the types of damage. You never say what
buffer damage is. I also don't know what a frame is in this context.
Regular damage handling marks parts of a plane as dirty/damaged. That is
per-plane damage handling. The individual planes more or less
independent from each other.
Buffer damage, I guess, marks the underlying buffer as dirty and
requires synchronization of the buffer with some backing storage. The
planes using that buffer are then updated more or less automatically.
Is that right?
In both cases the damage tracking information is the same, they mark
the damaged regions on the plane in framebuffer coordinates of the
framebuffer attached to the plane.
The problem as far as I understand is whether the driver expects that
to determine the area that changed in the plane (and a plane flush is
enough) or the area that changed since that same buffer was last used.
And why does it flicker? Is there old data stored somewhere?
It flickers because the framebuffer changed and so the damage tracking
is not used correctly to flush the damaged areas to the backing storage.
This is my understanding at least, please Sima or Simon correct me if I
got this wrong.
Best regards
Thomas
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature