qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: qemu-devel@nongnu.org
Cc: "Sriram Yagnaraman" <sriram.yagnaraman@ericsson.com>,
	"Akihiko Odaki" <akihiko.odaki@daynix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"John Snow" <jsnow@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Pierrick Bouvier" <pierrick.bouvier@linaro.org>,
	"Peter Xu" <peterx@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Fabiano Rosas" <farosas@suse.de>,
	qemu-arm@nongnu.org, "Thomas Huth" <thuth@redhat.com>,
	"Alexandre Iooss" <erdnaxe@crans.org>,
	"Gustavo Romero" <gustavo.romero@linaro.org>,
	"Markus Armbruster" <armbru@redhat.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Mahmoud Mandour" <ma.mandourr@gmail.com>,
	"Yiwei Zhang" <zzyiwei@gmail.com>,
	qemu-stable@nongnu.org
Subject: [PATCH v4 12/17] virtio-gpu: support context init multiple timeline
Date: Tue,  3 Jun 2025 12:01:59 +0100	[thread overview]
Message-ID: <20250603110204.838117-13-alex.bennee@linaro.org> (raw)
In-Reply-To: <20250603110204.838117-1-alex.bennee@linaro.org>

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")
Signed-off-by: Yiwei Zhang <zzyiwei@gmail.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Message-Id: <20250518152651.334115-1-zzyiwei@gmail.com>
[AJB: remove version history from commit message]
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 hw/display/virtio-gpu-virgl.c | 44 +++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index b4aa8abb96..cea2e12eb9 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -978,6 +978,15 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
     }
 
     trace_virtio_gpu_fence_ctrl(cmd->cmd_hdr.fence_id, cmd->cmd_hdr.type);
+#if VIRGL_VERSION_MAJOR >= 1
+    if (cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_INFO_RING_IDX) {
+        virgl_renderer_context_create_fence(cmd->cmd_hdr.ctx_id,
+                                            VIRGL_RENDERER_FENCE_FLAG_MERGEABLE,
+                                            cmd->cmd_hdr.ring_idx,
+                                            cmd->cmd_hdr.fence_id);
+        return;
+    }
+#endif
     virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, cmd->cmd_hdr.type);
 }
 
@@ -991,6 +1000,11 @@ static void virgl_write_fence(void *opaque, uint32_t fence)
          * the guest can end up emitting fences out of order
          * so we should check all fenced cmds not just the first one.
          */
+#if VIRGL_VERSION_MAJOR >= 1
+        if (cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_INFO_RING_IDX) {
+            continue;
+        }
+#endif
         if (cmd->cmd_hdr.fence_id > fence) {
             continue;
         }
@@ -1005,6 +1019,29 @@ static void virgl_write_fence(void *opaque, uint32_t fence)
     }
 }
 
+#if VIRGL_VERSION_MAJOR >= 1
+static void virgl_write_context_fence(void *opaque, uint32_t ctx_id,
+                                      uint32_t ring_idx, uint64_t fence_id) {
+    VirtIOGPU *g = opaque;
+    struct virtio_gpu_ctrl_command *cmd, *tmp;
+
+    QTAILQ_FOREACH_SAFE(cmd, &g->fenceq, next, tmp) {
+        if (cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_INFO_RING_IDX &&
+            cmd->cmd_hdr.ctx_id == ctx_id && cmd->cmd_hdr.ring_idx == ring_idx &&
+            cmd->cmd_hdr.fence_id <= fence_id) {
+            trace_virtio_gpu_fence_resp(cmd->cmd_hdr.fence_id);
+            virtio_gpu_ctrl_response_nodata(g, cmd, VIRTIO_GPU_RESP_OK_NODATA);
+            QTAILQ_REMOVE(&g->fenceq, cmd, next);
+            g_free(cmd);
+            g->inflight--;
+            if (virtio_gpu_stats_enabled(g->parent_obj.conf)) {
+                trace_virtio_gpu_dec_inflight_fences(g->inflight);
+            }
+        }
+    }
+}
+#endif
+
 static virgl_renderer_gl_context
 virgl_create_context(void *opaque, int scanout_idx,
                      struct virgl_renderer_gl_ctx_param *params)
@@ -1039,11 +1076,18 @@ static int virgl_make_context_current(void *opaque, int scanout_idx,
 }
 
 static struct virgl_renderer_callbacks virtio_gpu_3d_cbs = {
+#if VIRGL_VERSION_MAJOR >= 1
+    .version             = 3,
+#else
     .version             = 1,
+#endif
     .write_fence         = virgl_write_fence,
     .create_gl_context   = virgl_create_context,
     .destroy_gl_context  = virgl_destroy_context,
     .make_current        = virgl_make_context_current,
+#if VIRGL_VERSION_MAJOR >= 1
+    .write_context_fence = virgl_write_context_fence,
+#endif
 };
 
 static void virtio_gpu_print_stats(void *opaque)
-- 
2.47.2



  parent reply	other threads:[~2025-06-03 11:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-03 11:01 [PATCH v4 00/17] Maintainer updates for May (testing, plugins, virtio-gpu) - pre-PR Alex Bennée
2025-06-03 11:01 ` [PATCH v4 01/17] tests/docker: expose $HOME/.cache/qemu as docker volume Alex Bennée
2025-06-03 11:01 ` [PATCH v4 02/17] gitlab: disable debug info on CI builds Alex Bennée
2025-06-03 11:01 ` [PATCH v4 03/17] tests/tcg: make aarch64 boot.S handle different starting modes Alex Bennée
2025-06-05  8:29   ` Akihiko Odaki
2025-06-05  8:51     ` Alex Bennée
2025-06-06  9:53       ` Akihiko Odaki
2025-06-03 11:01 ` [PATCH v4 04/17] tests/qtest: Avoid unaligned access in IGB test Alex Bennée
2025-06-03 11:01 ` [PATCH v4 05/17] contrib/plugins: add a scaling factor to the ips arg Alex Bennée
2025-06-03 11:01 ` [PATCH v4 06/17] contrib/plugins: allow setting of instructions per quantum Alex Bennée
2025-06-03 11:01 ` [PATCH v4 07/17] MAINTAINERS: add myself to virtio-gpu for Odd Fixes Alex Bennée
2025-06-03 11:01 ` [PATCH v4 08/17] MAINTAINERS: add Akihiko and Dmitry as reviewers Alex Bennée
2025-06-05  8:35   ` Akihiko Odaki
2025-06-03 11:01 ` [PATCH v4 09/17] hw/display: re-arrange memory region tracking Alex Bennée
2025-06-05  8:34   ` Akihiko Odaki
2025-06-05 11:57     ` Alex Bennée
2025-06-06  9:40       ` Akihiko Odaki
2025-06-06 10:16         ` Alex Bennée
2025-06-06 15:02           ` Akihiko Odaki
2025-06-08 10:01             ` Akihiko Odaki
2025-06-03 11:01 ` [PATCH v4 10/17] virtio-gpu: refactor async blob unmapping Alex Bennée
2025-06-03 11:01 ` [PATCH v4 11/17] ui/gtk-gl-area: Remove extra draw call in refresh Alex Bennée
2025-06-03 11:01 ` Alex Bennée [this message]
2025-06-03 11:02 ` [PATCH v4 13/17] include/exec: fix assert in size_memop Alex Bennée
2025-06-03 11:02 ` [PATCH v4 14/17] include/gdbstub: fix include guard in commands.h Alex Bennée
2025-06-03 11:02 ` [PATCH v4 15/17] gdbstub: assert earlier in handle_read_all_regs Alex Bennée
2025-06-03 11:02 ` [PATCH v4 16/17] gdbstub: Implement qGDBServerVersion packet Alex Bennée
2025-06-03 11:02 ` [PATCH v4 17/17] gdbstub: update aarch64-core.xml Alex Bennée

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250603110204.838117-13-alex.bennee@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=akihiko.odaki@daynix.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=david@redhat.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=erdnaxe@crans.org \
    --cc=farosas@suse.de \
    --cc=gustavo.romero@linaro.org \
    --cc=jsnow@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=ma.mandourr@gmail.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=pierrick.bouvier@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=sriram.yagnaraman@ericsson.com \
    --cc=thuth@redhat.com \
    --cc=zzyiwei@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).