On 5/18/25 18:26, Yiwei Zhang wrote: > Venus and later native contexts have their own fence context along with > multiple timelines within. Fences wtih VIRTIO_GPU_FLAG_INFO_RING_IDX in > the flags must be dispatched to be created on the target context. Fence > signaling also has to be handled on the specific timeline within that > target context. > > Before this change, venus fencing is completely broken if the host > driver doesn't support implicit fencing with external memory objects. > Frames can go backwards along with random artifacts on screen if the > host driver doesn't attach an implicit fence to the render target. The > symptom could be hidden by certain guest wsi backend that waits on a > venus native VkFence object for the actual payload with limited present > modes or under special configs. e.g. x11 mailbox or xwayland. > > After this change, everything related to venus fencing starts making > sense. Confirmed this via guest and host side perfetto tracing.
Thanks for the patch, looks good. Haven't realized that ring idx support should've been a part of the context_init addition. Interestingly, it never showed a problem during venus testing in the past. Reviewed-by: Dmitry Osipenko <dmitry.osipe...@collabora.com> There could be multiple sources of a problem RE frames going backwards. I'm always testing venus in conjunction with async-cb patch that adds per-context fencing support and it doesn't help the X11 WSI issue discussed on [1]. Hence the Mesa WSI fixes still needed. [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34283 -- Best regards, Dmitry
