[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 12/17] virtio-gpu: support context init multiple timeline
From: |
Alex Bennée |
Subject: |
Re: [PULL 12/17] virtio-gpu: support context init multiple timeline |
Date: |
Fri, 20 Jun 2025 07:45:04 +0100 |
User-agent: |
mu4e 1.12.11; emacs 30.1 |
Yiwei Zhang <zzyiwei@gmail.com> writes:
> On Sun, Jun 8, 2025 at 1:24 AM Akihiko Odaki
> <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
>>
>> On 2025/06/06 1:26, Alex Bennée wrote:
>> > From: Yiwei Zhang <zzyiwei@gmail.com>
>> >
>> > 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.
>> >
>> > Cc: qemu-stable@nongnu.org
>> > Fixes: 94d0ea1c1928 ("virtio-gpu: Support Venus context")
>>
>> I suggest moving this in the front of the patch series to ease backporting.
>>
>> I also wonder if "[PULL 11/17] ui/gtk-gl-area: Remove extra draw call in
>> refresh" requires Cc: qemu-stable@nongnu.org. Fixing -display gtk,gl=on
>> for Wayland sounds as important as this patch.
>>
>> Regards,
>> Akihiko Odaki
>
> Hi Alex,
>
> +1 for Akihiko's point. I'm also curious when will the venus fix land
> in-tree?
We have a problem that there are two contradictory bugs - one that shows
up in the x86/kvm case and one in the aarch64/tcg case. Both are caused
by the weird lifetime semantics of the virgl resource vs QEMU memory
region and we haven't found a solution that solves both yet.
I'm currently busy with other stuff and need to do a sweep of my other
maintainer trees for 10.1. Once I've done that I'll have another go at
coming up with a solution unless someone else beats me to it.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
- Re: [PULL 04/17] tests/qtest: Avoid unaligned access in IGB test, (continued)
- [PULL 05/17] contrib/plugins: add a scaling factor to the ips arg, Alex Bennée, 2025/06/05
- [PULL 03/17] tests/tcg: make aarch64 boot.S handle different starting modes, Alex Bennée, 2025/06/05
- [PULL 06/17] contrib/plugins: allow setting of instructions per quantum, Alex Bennée, 2025/06/05
- [PULL 07/17] MAINTAINERS: add myself to virtio-gpu for Odd Fixes, Alex Bennée, 2025/06/05
- [PULL 10/17] virtio-gpu: refactor async blob unmapping, Alex Bennée, 2025/06/05
- [PULL 12/17] virtio-gpu: support context init multiple timeline, Alex Bennée, 2025/06/05
[PULL 13/17] include/exec: fix assert in size_memop, Alex Bennée, 2025/06/05
[PULL 08/17] MAINTAINERS: add Akihiko and Dmitry as reviewers, Alex Bennée, 2025/06/05
[PULL 09/17] hw/display: re-arrange memory region tracking, Alex Bennée, 2025/06/05