[PATCH v6 00/10] Support virtio-gpu DRM native context

[PATCH v6 00/10] Support virtio-gpu DRM native context

[Dmitry Osipenko]

This patchset adds DRM native context support to VirtIO-GPU on Qemu.

Contarary to Virgl and Venus contexts that mediates high level GFX APIs,
DRM native context [1] mediates lower level kernel driver UAPI, which
reflects in a less CPU overhead and less/simpler code needed to support it.
DRM context consists of a host and guest parts that have to be implemented
for each GPU driver. On a guest side, DRM context presents a virtual GPU as
a real/native host GPU device for GL/VK applications.

[1] https://www.youtube.com/watch?v=9sFP_yddLLQ

Today there are four DRM native context drivers existing in a wild:

  - Freedreno (Qualcomm SoC GPUs), completely upstreamed
  - AMDGPU, completely upstreamed
  - Intel (i915), merge requests are opened
  - Asahi (Apple SoC GPUs), partially merged upstream

# How to try out DRM context:

1. DRM context uses host blobs and on host requires latest 6.13 version
of Linux kernel that contains necessary KVM fixes.

2. Use latest Mesa (both guest and host) and libvirglrenderer versions.
 Use build flags documented in tha patch #10 of this series.

3. On guest, use latest Linux kernel v6.14-rc or newer.

Example Qemu cmdline that enables DRM context:

  qemu-system-x86_64 -device virtio-vga-gl,hostmem=4G,blob=on,drm_native_context=on \
      -machine q35,accel=kvm,memory-backend=mem1 \
      -object memory-backend-memfd,id=mem1,size=8G -m 8G

# Note about known performance problem in Qemu:

DRM contexts are mapping host blobs extensively and these mapping
operations work slowly in Qemu. Exact reason is unknown. Mappings work
fast on Crosvm For DRM contexts this problem is more visible than for
Venus/Virgl.

Changelog:

v6: - Fixed compilation warning using older version of virglrenderer,
      which wasn't fixed properly in v5.

    - Added t-bs from Alex Bennée.

    - Added patches to improve virgl/venus doc by adding links
      to the Mesa doc as was suggested by Akihiko Odaki.

    - Updated patch that documents guest/host requirements. Added
      links to Asahi nctx and reworked the doc structure by adding
      requirements to each context-type section instead of having
      one big blob or requirements, which was objected by Akihiko Odaki.

v5: - Added r-bs from Akihiko Odaki.

    - Added acks from Michael Tsirkin.

    - Fixed compilation warning using older version of virglrenderer that
      was reported by Alex Bennée. Noticed that I need to keep old
      virgl_write_fence() code around for the older virglrenderer in
      "Support  asynchronous fencing" patch, so added it back and verified
      that old virglrenderer works properly.

    - Added new patch from Alex Bennée that adds more virtio-gpu 
      documentation with a couple corrections and additions to it from me.

    - Rebased patches on top of latest staging tree.

v4: - Improved SDL2/dmabuf patch by reusing existing Meson X11 config 
      option, better handling EGL error and extending comment telling
      that it's safe to enable SDL2 EGL preference hint. As was suggested
      by Akihiko Odaki.

    - Replaced another QSLIST_FOREACH_SAFE with QSLIST_EMPTY+FIRST in
      the async-fencing patch for more consistency of the code. As was
      suggested by Akihiko Odaki.

    - Added missing braces around if-statement that was spotted by
      Alex Bennée.

    - Renamed 'drm=on' option of virtio-gpu-gl device to 
      'drm_native_context=on' for more clarity as was suggested by 
      Alex Bennée. Haven't added added new context-type option that 
      was also proposed by Alex, might do it with a separate patch.
      This context-type option will duplicate and depecate existing
      options, but in a longer run likely will be worthwhile adding
      it.

    - Dropped Linux headers-update patch as headers has been updated
      in the staging tree.

v3: - Improved EGL presence-check code on X11 systems for the SDL2
      hint that prefers EGL over GLX by using better ifdefs and checking
      Xlib presence at a build time to avoid build failure if lib SDL2
      and system are configured with a disabled X11 support. Also added
      clarifying comment telling that X11 hint doesn't affect Wayland
      systems. Suggested by Akihiko Odaki.

    - Corrected strerror(err) that used negative error where it should
      be positive and vice versa that was caught by Akihiko Odaki. Added
      clarifying comment for the case where we get positive error code
      from virglrenderer that differs from other virglrenderer API functions.

    - Improved QSLIST usage by dropping mutex protecting the async fence
      list and using atomic variant of QSLIST helpers instead. Switched away
      from using FOREACH helper to improve readability of the code, showing
      that we don't precess list in unoptimal way. Like was suggested by
      Akihiko Odaki.

    - Updated patchset base to Venus v18.

v2: - Updated SDL2-dmabuf patch by making use of error_report() and
      checking presense of X11+EGL in the system before making SDL2
      to prefer EGL backend over GLX, suggested by Akihiko Odaki.

    - Improved SDL2's dmabuf-presence check that wasn't done properly
      in v1, where EGL was set up only after first console was fully
      inited, and thus, SDL's display .has_dmabuf callback didn't work
      for the first console. Now dmabuf support status is pre-checked
      before console is registered.

    - Updated commit description of the patch that fixes SDL2's context
      switching logic with a more detailed explanation of the problem.
      Suggested by Akihiko Odaki.

    - Corrected rebase typo in the async-fencing patch and switched
      async-fencing to use a sigle-linked list instead of the double,
      as was suggested by Akihiko Odaki.

    - Replaced "=true" with "=on" in the DRM native context documentation
      example and made virtio_gpu_virgl_init() to fail with a error message
      if DRM context can't be initialized instead of giving a warning
      message, as was suggested by Akihiko Odaki.

    - Added patchew's dependecy tag to the cover letter as was suggested by
      Akihiko Odaki.

Alex Bennée (1):
  docs/system: virtio-gpu: Document host/guest requirements

Dmitry Osipenko (8):
  ui/sdl2: Restore original context after new context creation
  virtio-gpu: Handle virgl fence creation errors
  virtio-gpu: Support asynchronous fencing
  virtio-gpu: Support DRM native context
  ui/sdl2: Don't disable scanout when display is refreshed
  ui/gtk: Don't disable scanout when display is refreshed
  docs/system: virtio-gpu: Add link to Mesa VirGL doc
  docs/system: virtio-gpu: Update Venus link

Pierre-Eric Pelloux-Prayer (1):
  ui/sdl2: Implement dpy dmabuf functions

 docs/system/devices/virtio-gpu.rst | 123 +++++++++++++++++++++-
 hw/display/virtio-gpu-gl.c         |   5 +
 hw/display/virtio-gpu-virgl.c      | 164 ++++++++++++++++++++++++++++-
 hw/display/virtio-gpu.c            |  15 +++
 include/hw/virtio/virtio-gpu.h     |  16 +++
 include/ui/sdl2.h                  |   7 ++
 meson.build                        |   6 +-
 ui/gtk-egl.c                       |   1 -
 ui/gtk-gl-area.c                   |   1 -
 ui/sdl2-gl.c                       |  68 +++++++++++-
 ui/sdl2.c                          |  42 ++++++++
 11 files changed, 437 insertions(+), 11 deletions(-)

-- 
2.47.1

[PATCH v6 01/10] ui/sdl2: Restore original context after new context creation

[Dmitry Osipenko]

SDL API changes GL context to a newly created GL context, which differs
from other GL providers that don't switch context. Change SDL backend to
restore the original GL context. This allows Qemu's virtio-gpu to support
new virglrenderer async-fencing feature for Virgl contexts, otherwise
virglrenderer's vrend creates a fence-sync context on the Qemu's
main-loop thread that erroneously stays in-use by the main-loop after
creation, not allowing vrend's fence-sync thread switch to this new
context that belongs to it.

Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 ui/sdl2-gl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ui/sdl2-gl.c b/ui/sdl2-gl.c
index e01d9ab0c7bf..b1fe96d6af22 100644
--- a/ui/sdl2-gl.c
+++ b/ui/sdl2-gl.c
@@ -168,6 +168,9 @@ QEMUGLContext sdl2_gl_create_context(DisplayGLCtx *dgc,
                             SDL_GL_CONTEXT_PROFILE_ES);
         ctx = SDL_GL_CreateContext(scon->real_window);
     }
+
+    SDL_GL_MakeCurrent(scon->real_window, scon->winctx);
+
     return (QEMUGLContext)ctx;
 }
 
-- 
2.47.1

[PATCH v6 02/10] ui/sdl2: Implement dpy dmabuf functions

[Dmitry Osipenko]

From: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>

If EGL is used, we can rely on dmabuf to import textures without
doing copies.

To get this working on X11, we use the existing SDL hint:
SDL_HINT_VIDEO_X11_FORCE_EGL (because dmabuf can't be used with GLX).

Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 include/ui/sdl2.h |  7 ++++++
 meson.build       |  6 ++---
 ui/sdl2-gl.c      | 64 +++++++++++++++++++++++++++++++++++++++++++++++
 ui/sdl2.c         | 42 +++++++++++++++++++++++++++++++
 4 files changed, 115 insertions(+), 4 deletions(-)

diff --git a/include/ui/sdl2.h b/include/ui/sdl2.h
index dbe6e3d9739b..9daf5ecffae7 100644
--- a/include/ui/sdl2.h
+++ b/include/ui/sdl2.h
@@ -45,6 +45,7 @@ struct sdl2_console {
     bool gui_keysym;
     SDL_GLContext winctx;
     QKbdState *kbd;
+    bool has_dmabuf;
 #ifdef CONFIG_OPENGL
     QemuGLShader *gls;
     egl_fb guest_fb;
@@ -96,5 +97,11 @@ void sdl2_gl_scanout_texture(DisplayChangeListener *dcl,
                              void *d3d_tex2d);
 void sdl2_gl_scanout_flush(DisplayChangeListener *dcl,
                            uint32_t x, uint32_t y, uint32_t w, uint32_t h);
+void sdl2_gl_scanout_dmabuf(DisplayChangeListener *dcl,
+                            QemuDmaBuf *dmabuf);
+void sdl2_gl_release_dmabuf(DisplayChangeListener *dcl,
+                            QemuDmaBuf *dmabuf);
+bool sdl2_gl_has_dmabuf(DisplayChangeListener *dcl);
+void sdl2_gl_console_init(struct sdl2_console *scon);
 
 #endif /* SDL2_H */
diff --git a/meson.build b/meson.build
index 15a066043b7b..dfee104582b0 100644
--- a/meson.build
+++ b/meson.build
@@ -1964,10 +1964,8 @@ if get_option('gtk') \
   endif
 endif
 
-x11 = not_found
-if gtkx11.found()
-  x11 = dependency('x11', method: 'pkg-config', required: gtkx11.found())
-endif
+x11 = dependency('x11', method: 'pkg-config', required: gtkx11.found())
+
 png = not_found
 if get_option('png').allowed() and have_system
    png = dependency('libpng', version: '>=1.6.34', required: get_option('png'),
diff --git a/ui/sdl2-gl.c b/ui/sdl2-gl.c
index b1fe96d6af22..8d53e340d40d 100644
--- a/ui/sdl2-gl.c
+++ b/ui/sdl2-gl.c
@@ -26,6 +26,8 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/main-loop.h"
+#include "qemu/error-report.h"
 #include "ui/console.h"
 #include "ui/input.h"
 #include "ui/sdl2.h"
@@ -249,3 +251,65 @@ void sdl2_gl_scanout_flush(DisplayChangeListener *dcl,
 
     SDL_GL_SwapWindow(scon->real_window);
 }
+
+void sdl2_gl_scanout_dmabuf(DisplayChangeListener *dcl,
+                            QemuDmaBuf *dmabuf)
+{
+    struct sdl2_console *scon = container_of(dcl, struct sdl2_console, dcl);
+
+    assert(scon->opengl);
+    SDL_GL_MakeCurrent(scon->real_window, scon->winctx);
+
+    egl_dmabuf_import_texture(dmabuf);
+    if (!qemu_dmabuf_get_texture(dmabuf)) {
+        error_report("%s: failed fd=%d", __func__, qemu_dmabuf_get_fd(dmabuf));
+        return;
+    }
+
+    sdl2_gl_scanout_texture(dcl, qemu_dmabuf_get_texture(dmabuf), false,
+                            qemu_dmabuf_get_width(dmabuf),
+                            qemu_dmabuf_get_height(dmabuf),
+                            0, 0,
+                            qemu_dmabuf_get_width(dmabuf),
+                            qemu_dmabuf_get_height(dmabuf),
+                            NULL);
+
+    if (qemu_dmabuf_get_allow_fences(dmabuf)) {
+        scon->guest_fb.dmabuf = dmabuf;
+    }
+}
+
+void sdl2_gl_release_dmabuf(DisplayChangeListener *dcl,
+                            QemuDmaBuf *dmabuf)
+{
+    egl_dmabuf_release_texture(dmabuf);
+}
+
+bool sdl2_gl_has_dmabuf(DisplayChangeListener *dcl)
+{
+    struct sdl2_console *scon = container_of(dcl, struct sdl2_console, dcl);
+
+    return scon->has_dmabuf;
+}
+
+void sdl2_gl_console_init(struct sdl2_console *scon)
+{
+    bool hidden = scon->hidden;
+
+    scon->hidden = true;
+    scon->surface = qemu_create_displaysurface(1, 1);
+    sdl2_window_create(scon);
+
+    /*
+     * QEMU checks whether console supports dma-buf before switching
+     * to the console.  To break this chicken-egg problem we pre-check
+     * dma-buf availability beforehand using a dummy SDL window.
+     */
+    scon->has_dmabuf = qemu_egl_has_dmabuf();
+
+    sdl2_window_destroy(scon);
+    qemu_free_displaysurface(scon->surface);
+
+    scon->surface = NULL;
+    scon->hidden = hidden;
+}
diff --git a/ui/sdl2.c b/ui/sdl2.c
index 445eb1dd9f9a..3e262b994231 100644
--- a/ui/sdl2.c
+++ b/ui/sdl2.c
@@ -36,6 +36,10 @@
 #include "qemu/log.h"
 #include "qemu-main.h"
 
+#ifdef CONFIG_X11
+#include <X11/Xlib.h>
+#endif
+
 static int sdl2_num_outputs;
 static struct sdl2_console *sdl2_console;
 
@@ -121,6 +125,9 @@ void sdl2_window_create(struct sdl2_console *scon)
         /* The SDL renderer is only used by sdl2-2D, when OpenGL is disabled */
         scon->real_renderer = SDL_CreateRenderer(scon->real_window, -1, 0);
     }
+
+    qemu_egl_display = eglGetCurrentDisplay();
+
     sdl_update_caption(scon);
 }
 
@@ -821,6 +828,10 @@ static const DisplayChangeListenerOps dcl_gl_ops = {
     .dpy_gl_scanout_disable  = sdl2_gl_scanout_disable,
     .dpy_gl_scanout_texture  = sdl2_gl_scanout_texture,
     .dpy_gl_update           = sdl2_gl_scanout_flush,
+
+    .dpy_gl_scanout_dmabuf   = sdl2_gl_scanout_dmabuf,
+    .dpy_gl_release_dmabuf   = sdl2_gl_release_dmabuf,
+    .dpy_has_dmabuf          = sdl2_gl_has_dmabuf,
 };
 
 static bool
@@ -848,6 +859,35 @@ static void sdl2_display_early_init(DisplayOptions *o)
     }
 }
 
+static void sdl2_set_hint_x11_force_egl(void)
+{
+#if defined(SDL_HINT_VIDEO_X11_FORCE_EGL) && defined(CONFIG_OPENGL) && \
+    defined(CONFIG_X11)
+    Display *x_disp = XOpenDisplay(NULL);
+    EGLDisplay egl_display;
+
+    if (!x_disp) {
+        return;
+    }
+
+    /* Prefer EGL over GLX to get dma-buf support. */
+    egl_display = eglGetDisplay((EGLNativeDisplayType)x_disp);
+
+    if (egl_display != EGL_NO_DISPLAY) {
+        /*
+         * Setting X11_FORCE_EGL hint doesn't make SDL to prefer X11 over
+         * Wayland. SDL will use Wayland driver even if XWayland presents.
+         * It's always safe to set the hint even if X11 is not used by SDL.
+         * SDL will work regardless of the hint.
+         */
+        SDL_SetHint(SDL_HINT_VIDEO_X11_FORCE_EGL, "1");
+        eglTerminate(egl_display);
+    }
+
+    XCloseDisplay(x_disp);
+#endif
+}
+
 static void sdl2_display_init(DisplayState *ds, DisplayOptions *o)
 {
     uint8_t data = 0;
@@ -878,6 +918,7 @@ static void sdl2_display_init(DisplayState *ds, DisplayOptions *o)
     SDL_SetHint(SDL_HINT_ALLOW_ALT_TAB_WHILE_GRABBED, "0");
 #endif
     SDL_SetHint(SDL_HINT_WINDOWS_NO_CLOSE_ON_ALT_F4, "1");
+    sdl2_set_hint_x11_force_egl();
     SDL_EnableScreenSaver();
     memset(&info, 0, sizeof(info));
     SDL_VERSION(&info.version);
@@ -924,6 +965,7 @@ static void sdl2_display_init(DisplayState *ds, DisplayOptions *o)
         sdl2_console[i].kbd = qkbd_state_init(con);
         if (display_opengl) {
             qemu_console_set_display_gl_ctx(con, &sdl2_console[i].dgc);
+            sdl2_gl_console_init(&sdl2_console[i]);
         }
         register_displaychangelistener(&sdl2_console[i].dcl);
 
-- 
2.47.1

[PATCH v6 03/10] virtio-gpu: Handle virgl fence creation errors

[Dmitry Osipenko]

Print out error messages when virgl fence creation fails to aid debugging
of the fence-related bugs.

Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 hw/display/virtio-gpu-virgl.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 145a0b387956..2eb6aaab4e84 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -872,6 +872,7 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
                                       struct virtio_gpu_ctrl_command *cmd)
 {
     bool cmd_suspended = false;
+    int ret;
 
     VIRTIO_GPU_FILL_CMD(cmd->cmd_hdr);
 
@@ -970,7 +971,17 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
     }
 
     trace_virtio_gpu_fence_ctrl(cmd->cmd_hdr.fence_id, cmd->cmd_hdr.type);
-    virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, cmd->cmd_hdr.type);
+
+    /*
+     * Unlike other virglrenderer functions, this one returns a positive
+     * error code.
+     */
+    ret = virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, 0);
+    if (ret) {
+        qemu_log_mask(LOG_GUEST_ERROR,
+                      "%s: virgl_renderer_create_fence error: %s",
+                      __func__, strerror(ret));
+    }
 }
 
 static void virgl_write_fence(void *opaque, uint32_t fence)
-- 
2.47.1

[PATCH v6 04/10] virtio-gpu: Support asynchronous fencing

[Dmitry Osipenko]

Support asynchronous fencing feature of virglrenderer. It allows Qemu to
handle fence as soon as it's signalled instead of periodically polling
the fence status. This feature is required for enabling DRM context
support in Qemu because legacy fencing mode isn't supported for DRM
contexts in virglrenderer.

Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 hw/display/virtio-gpu-gl.c     |   3 +
 hw/display/virtio-gpu-virgl.c  | 147 +++++++++++++++++++++++++++++++--
 include/hw/virtio/virtio-gpu.h |  13 +++
 3 files changed, 154 insertions(+), 9 deletions(-)

diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index 683fad3bf8a8..d9bb50ac1d4a 100644
--- a/hw/display/virtio-gpu-gl.c
+++ b/hw/display/virtio-gpu-gl.c
@@ -169,6 +169,9 @@ static void virtio_gpu_gl_device_unrealize(DeviceState *qdev)
     if (gl->renderer_state >= RS_INITED) {
 #if VIRGL_VERSION_MAJOR >= 1
         qemu_bh_delete(gl->cmdq_resume_bh);
+
+        virtio_gpu_virgl_reset_async_fences(g);
+        qemu_bh_delete(gl->async_fence_bh);
 #endif
         if (virtio_gpu_stats_enabled(g->parent_obj.conf)) {
             timer_free(gl->print_stats);
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index 2eb6aaab4e84..ee896eced67c 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -871,6 +871,7 @@ static void virgl_cmd_set_scanout_blob(VirtIOGPU *g,
 void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
                                       struct virtio_gpu_ctrl_command *cmd)
 {
+    VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
     bool cmd_suspended = false;
     int ret;
 
@@ -972,15 +973,34 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
 
     trace_virtio_gpu_fence_ctrl(cmd->cmd_hdr.fence_id, cmd->cmd_hdr.type);
 
-    /*
-     * Unlike other virglrenderer functions, this one returns a positive
-     * error code.
-     */
-    ret = virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, 0);
-    if (ret) {
-        qemu_log_mask(LOG_GUEST_ERROR,
-                      "%s: virgl_renderer_create_fence error: %s",
-                      __func__, strerror(ret));
+    if (gl->context_fence_enabled &&
+        (cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_INFO_RING_IDX)) {
+#if VIRGL_VERSION_MAJOR >= 1
+        uint32_t flags = 0;
+
+        ret = virgl_renderer_context_create_fence(cmd->cmd_hdr.ctx_id, flags,
+                                                  cmd->cmd_hdr.ring_idx,
+                                                  cmd->cmd_hdr.fence_id);
+        if (ret) {
+            qemu_log_mask(LOG_GUEST_ERROR,
+                          "%s: virgl_renderer_context_create_fence error: %s",
+                          __func__, strerror(-ret));
+        }
+#else
+        /* gl->context_fence_enabled cannot be set with older virglrenderer */
+        g_assert_not_reached();
+#endif
+    } else {
+        /*
+         * Unlike other virglrenderer functions, this one returns a positive
+         * error code.
+         */
+        ret = virgl_renderer_create_fence(cmd->cmd_hdr.fence_id, 0);
+        if (ret) {
+            qemu_log_mask(LOG_GUEST_ERROR,
+                          "%s: virgl_renderer_create_fence error: %s",
+                          __func__, strerror(ret));
+        }
     }
 }
 
@@ -1008,6 +1028,102 @@ static void virgl_write_fence(void *opaque, uint32_t fence)
     }
 }
 
+void virtio_gpu_virgl_reset_async_fences(VirtIOGPU *g)
+{
+    struct virtio_gpu_virgl_context_fence *f;
+    VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
+
+    while (!QSLIST_EMPTY(&gl->async_fenceq)) {
+        f = QSLIST_FIRST(&gl->async_fenceq);
+
+        QSLIST_REMOVE_HEAD(&gl->async_fenceq, next);
+
+        g_free(f);
+    }
+}
+
+#if VIRGL_VERSION_MAJOR >= 1
+static void virtio_gpu_virgl_async_fence_bh(void *opaque)
+{
+    QSLIST_HEAD(, virtio_gpu_virgl_context_fence) async_fenceq;
+    struct virtio_gpu_ctrl_command *cmd, *tmp;
+    struct virtio_gpu_virgl_context_fence *f;
+    VirtIOGPU *g = opaque;
+    VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
+
+    QSLIST_MOVE_ATOMIC(&async_fenceq, &gl->async_fenceq);
+
+    while (!QSLIST_EMPTY(&async_fenceq)) {
+        f = QSLIST_FIRST(&async_fenceq);
+
+        QSLIST_REMOVE_HEAD(&async_fenceq, next);
+
+        QTAILQ_FOREACH_SAFE(cmd, &g->fenceq, next, tmp) {
+            /*
+             * the guest can end up emitting fences out of order
+             * so we should check all fenced cmds not just the first one.
+             */
+            if (cmd->cmd_hdr.fence_id > f->fence_id) {
+                continue;
+            }
+            if (cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_INFO_RING_IDX) {
+                if (cmd->cmd_hdr.ring_idx != f->ring_idx) {
+                    continue;
+                }
+                if (cmd->cmd_hdr.ctx_id != f->ctx_id) {
+                    continue;
+                }
+            } else if (f->ring_idx >= 0) {
+                /* ctx0 GL-query fences don't have ring info */
+                continue;
+            }
+            virtio_gpu_ctrl_response_nodata(g, cmd, VIRTIO_GPU_RESP_OK_NODATA);
+            QTAILQ_REMOVE(&g->fenceq, cmd, next);
+            g_free(cmd);
+        }
+
+        trace_virtio_gpu_fence_resp(f->fence_id);
+        g_free(f);
+        g->inflight--;
+        if (virtio_gpu_stats_enabled(g->parent_obj.conf)) {
+            trace_virtio_gpu_dec_inflight_fences(g->inflight);
+        }
+    }
+}
+
+static void
+virtio_gpu_virgl_push_async_fence(VirtIOGPU *g, uint32_t ctx_id,
+                                  int64_t ring_idx, uint64_t fence_id)
+{
+    struct virtio_gpu_virgl_context_fence *f;
+    VirtIOGPUGL *gl = VIRTIO_GPU_GL(g);
+
+    f = g_new(struct virtio_gpu_virgl_context_fence, 1);
+    f->ctx_id = ctx_id;
+    f->ring_idx = ring_idx;
+    f->fence_id = fence_id;
+
+    QSLIST_INSERT_HEAD_ATOMIC(&gl->async_fenceq, f, next);
+
+    qemu_bh_schedule(gl->async_fence_bh);
+}
+
+static void virgl_write_async_fence(void *opaque, uint32_t fence)
+{
+    VirtIOGPU *g = opaque;
+
+    virtio_gpu_virgl_push_async_fence(g, 0, -1, fence);
+}
+
+static void virgl_write_async_context_fence(void *opaque, uint32_t ctx_id,
+                                            uint32_t ring_idx, uint64_t fence)
+{
+    VirtIOGPU *g = opaque;
+
+    virtio_gpu_virgl_push_async_fence(g, ctx_id, ring_idx, fence);
+}
+#endif
+
 static virgl_renderer_gl_context
 virgl_create_context(void *opaque, int scanout_idx,
                      struct virgl_renderer_gl_ctx_param *params)
@@ -1095,6 +1211,8 @@ void virtio_gpu_virgl_reset_scanout(VirtIOGPU *g)
         dpy_gfx_replace_surface(g->parent_obj.scanout[i].con, NULL);
         dpy_gl_scanout_disable(g->parent_obj.scanout[i].con);
     }
+
+    virtio_gpu_virgl_reset_async_fences(g);
 }
 
 void virtio_gpu_virgl_reset(VirtIOGPU *g)
@@ -1112,6 +1230,13 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
     if (qemu_egl_display) {
         virtio_gpu_3d_cbs.version = 4;
         virtio_gpu_3d_cbs.get_egl_display = virgl_get_egl_display;
+#if VIRGL_VERSION_MAJOR >= 1
+        virtio_gpu_3d_cbs.write_fence         = virgl_write_async_fence;
+        virtio_gpu_3d_cbs.write_context_fence = virgl_write_async_context_fence;
+        flags |= VIRGL_RENDERER_ASYNC_FENCE_CB;
+        flags |= VIRGL_RENDERER_THREAD_SYNC;
+        gl->context_fence_enabled = true;
+#endif
     }
 #endif
 #ifdef VIRGL_RENDERER_D3D11_SHARE_TEXTURE
@@ -1145,6 +1270,10 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
     gl->cmdq_resume_bh = aio_bh_new(qemu_get_aio_context(),
                                     virtio_gpu_virgl_resume_cmdq_bh,
                                     g);
+
+    gl->async_fence_bh = aio_bh_new(qemu_get_aio_context(),
+                                    virtio_gpu_virgl_async_fence_bh,
+                                    g);
 #endif
 
     return 0;
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index a42957c4e2cc..bd2cccdc60d7 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -230,6 +230,13 @@ struct VirtIOGPUClass {
                              Error **errp);
 };
 
+struct virtio_gpu_virgl_context_fence {
+    uint32_t ctx_id;
+    int64_t ring_idx;
+    uint64_t fence_id;
+    QSLIST_ENTRY(virtio_gpu_virgl_context_fence) next;
+};
+
 /* VirtIOGPUGL renderer states */
 typedef enum {
     RS_START,       /* starting state */
@@ -247,6 +254,11 @@ struct VirtIOGPUGL {
     QEMUTimer *print_stats;
 
     QEMUBH *cmdq_resume_bh;
+
+    QEMUBH *async_fence_bh;
+    QSLIST_HEAD(, virtio_gpu_virgl_context_fence) async_fenceq;
+
+    bool context_fence_enabled;
 };
 
 struct VhostUserGPU {
@@ -376,5 +388,6 @@ void virtio_gpu_virgl_reset_scanout(VirtIOGPU *g);
 void virtio_gpu_virgl_reset(VirtIOGPU *g);
 int virtio_gpu_virgl_init(VirtIOGPU *g);
 GArray *virtio_gpu_virgl_get_capsets(VirtIOGPU *g);
+void virtio_gpu_virgl_reset_async_fences(VirtIOGPU *g);
 
 #endif
-- 
2.47.1

Re: [PATCH v6 04/10] virtio-gpu: Support asynchronous fencing

[Alex Bennée]

Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:

> Support asynchronous fencing feature of virglrenderer. It allows Qemu to
> handle fence as soon as it's signalled instead of periodically polling
> the fence status. This feature is required for enabling DRM context
> support in Qemu because legacy fencing mode isn't supported for DRM
> contexts in virglrenderer.
>
> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Tested-by: Alex Bennée <alex.bennee@linaro.org>
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

[PATCH v6 05/10] virtio-gpu: Support DRM native context

[Dmitry Osipenko]

Add support for DRM native contexts to VirtIO-GPU. DRM context is enabled
using a new virtio-gpu-gl device option "drm_native_context=on".

Unlike Virgl and Venus contexts that operate on application API level,
DRM native contexts work on a kernel UAPI level. This lower level results
in a lightweight context implementations that yield better performance.

Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 docs/system/devices/virtio-gpu.rst | 11 +++++++++++
 hw/display/virtio-gpu-gl.c         |  2 ++
 hw/display/virtio-gpu-virgl.c      | 22 ++++++++++++++++++++++
 hw/display/virtio-gpu.c            | 15 +++++++++++++++
 include/hw/virtio/virtio-gpu.h     |  3 +++
 5 files changed, 53 insertions(+)

diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst
index b7eb0fc0e727..f20c60016376 100644
--- a/docs/system/devices/virtio-gpu.rst
+++ b/docs/system/devices/virtio-gpu.rst
@@ -82,6 +82,17 @@ of virtio-gpu host memory window. This is typically between 256M and 8G.
 
 .. _venus: https://gitlab.freedesktop.org/virgl/venus-protocol/
 
+DRM native context is supported since release of `virglrenderer`_ v1.0.0
+using `drm`_ protocol.  ``DRM`` virtio-gpu capability set ("capset") requires
+host blob support (``hostmem`` and ``blob`` fields) and should be enabled
+using ``drm_native_context`` field.  The ``hostmem`` field specifies the size
+of virtio-gpu host memory window. This is typically between 256M and 8G.
+
+.. parsed-literal::
+    -device virtio-gpu-gl,hostmem=8G,blob=on,drm_native_context=on
+
+.. _drm: https://gitlab.freedesktop.org/virgl/virglrenderer/-/tree/main/src/drm
+
 virtio-gpu rutabaga
 -------------------
 
diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
index d9bb50ac1d4a..5f374ad56396 100644
--- a/hw/display/virtio-gpu-gl.c
+++ b/hw/display/virtio-gpu-gl.c
@@ -159,6 +159,8 @@ static const Property virtio_gpu_gl_properties[] = {
                     VIRTIO_GPU_FLAG_STATS_ENABLED, false),
     DEFINE_PROP_BIT("venus", VirtIOGPU, parent_obj.conf.flags,
                     VIRTIO_GPU_FLAG_VENUS_ENABLED, false),
+    DEFINE_PROP_BIT("drm_native_context", VirtIOGPU, parent_obj.conf.flags,
+                    VIRTIO_GPU_FLAG_DRM_ENABLED, false),
 };
 
 static void virtio_gpu_gl_device_unrealize(DeviceState *qdev)
diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
index ee896eced67c..184ad2c588f7 100644
--- a/hw/display/virtio-gpu-virgl.c
+++ b/hw/display/virtio-gpu-virgl.c
@@ -1248,6 +1248,19 @@ int virtio_gpu_virgl_init(VirtIOGPU *g)
     if (virtio_gpu_venus_enabled(g->parent_obj.conf)) {
         flags |= VIRGL_RENDERER_VENUS | VIRGL_RENDERER_RENDER_SERVER;
     }
+    if (virtio_gpu_drm_enabled(g->parent_obj.conf)) {
+        flags |= VIRGL_RENDERER_DRM;
+
+        if (!gl->context_fence_enabled) {
+            /*
+             * Virglrenderer skips enabling DRM context support without
+             * enabled async-fence feature. VirtIO-GPU will initialize
+             * successfully, but DRM context won't be available in guest.
+             */
+            error_report("DRM native context requires EGL display");
+            return -EINVAL;
+        }
+    }
 #endif
 
     ret = virgl_renderer_init(g, flags, &virtio_gpu_3d_cbs);
@@ -1310,5 +1323,14 @@ GArray *virtio_gpu_virgl_get_capsets(VirtIOGPU *g)
         }
     }
 
+    if (virtio_gpu_drm_enabled(g->parent_obj.conf)) {
+        virgl_renderer_get_cap_set(VIRTIO_GPU_CAPSET_DRM,
+                                   &capset_max_ver,
+                                   &capset_max_size);
+        if (capset_max_size) {
+            virtio_gpu_virgl_add_capset(capset_ids, VIRTIO_GPU_CAPSET_DRM);
+        }
+    }
+
     return capset_ids;
 }
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
index 11a7a8575027..165a0976480d 100644
--- a/hw/display/virtio-gpu.c
+++ b/hw/display/virtio-gpu.c
@@ -1505,6 +1505,21 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error **errp)
 #endif
     }
 
+    if (virtio_gpu_drm_enabled(g->parent_obj.conf)) {
+#ifdef VIRGL_VERSION_MAJOR
+    #if VIRGL_VERSION_MAJOR >= 1
+        if (!virtio_gpu_blob_enabled(g->parent_obj.conf) ||
+            !virtio_gpu_hostmem_enabled(g->parent_obj.conf)) {
+            error_setg(errp, "drm requires enabled blob and hostmem options");
+            return;
+        }
+    #else
+        error_setg(errp, "old virglrenderer, drm unsupported");
+        return;
+    #endif
+#endif
+    }
+
     if (!virtio_gpu_base_device_realize(qdev,
                                         virtio_gpu_handle_ctrl_cb,
                                         virtio_gpu_handle_cursor_cb,
diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
index bd2cccdc60d7..dcdf52b192b5 100644
--- a/include/hw/virtio/virtio-gpu.h
+++ b/include/hw/virtio/virtio-gpu.h
@@ -99,6 +99,7 @@ enum virtio_gpu_base_conf_flags {
     VIRTIO_GPU_FLAG_RUTABAGA_ENABLED,
     VIRTIO_GPU_FLAG_VENUS_ENABLED,
     VIRTIO_GPU_FLAG_RESOURCE_UUID_ENABLED,
+    VIRTIO_GPU_FLAG_DRM_ENABLED,
 };
 
 #define virtio_gpu_virgl_enabled(_cfg) \
@@ -121,6 +122,8 @@ enum virtio_gpu_base_conf_flags {
     (_cfg.hostmem > 0)
 #define virtio_gpu_venus_enabled(_cfg) \
     (_cfg.flags & (1 << VIRTIO_GPU_FLAG_VENUS_ENABLED))
+#define virtio_gpu_drm_enabled(_cfg) \
+    (_cfg.flags & (1 << VIRTIO_GPU_FLAG_DRM_ENABLED))
 
 struct virtio_gpu_base_conf {
     uint32_t max_outputs;
-- 
2.47.1

[PATCH v6 06/10] ui/sdl2: Don't disable scanout when display is refreshed

[Dmitry Osipenko]

Display refreshment is invoked by a timer and it erroneously disables
the active scanout if it happens to be invoked after scanout has been
enabled. This offending scanout-disable race condition with a timer
can be easily hit when Qemu runs with a disabled vsync by using SDL or
GTK displays (with vblank_mode=0 for GTK). Refreshment of display's
content shouldn't disable the active display. Fix it by keeping the
scanout's state unchanged when display is redrawn.

Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 ui/sdl2-gl.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/ui/sdl2-gl.c b/ui/sdl2-gl.c
index 8d53e340d40d..31f8fbe03286 100644
--- a/ui/sdl2-gl.c
+++ b/ui/sdl2-gl.c
@@ -53,7 +53,6 @@ static void sdl2_gl_render_surface(struct sdl2_console *scon)
     int ww, wh;
 
     SDL_GL_MakeCurrent(scon->real_window, scon->winctx);
-    sdl2_set_scanout_mode(scon, false);
 
     SDL_GetWindowSize(scon->real_window, &ww, &wh);
     surface_gl_setup_viewport(scon->gls, scon->surface, ww, wh);
-- 
2.47.1

[PATCH v6 07/10] ui/gtk: Don't disable scanout when display is refreshed

[Dmitry Osipenko]

Display refreshment is invoked by a timer and it erroneously disables
the active scanout if it happens to be invoked after scanout has been
enabled. This offending scanout-disable race condition with a timer
can be easily hit when Qemu runs with a disabled vsync by using SDL or
GTK displays (with vblank_mode=0 for GTK). Refreshment of display's
content shouldn't disable the active display. Fix it by keeping the
scanout's state unchanged when display is redrawn.

Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 ui/gtk-egl.c     | 1 -
 ui/gtk-gl-area.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c
index f7a428c86a8d..0d1547d63ad0 100644
--- a/ui/gtk-egl.c
+++ b/ui/gtk-egl.c
@@ -179,7 +179,6 @@ void gd_egl_refresh(DisplayChangeListener *dcl)
 
     if (vc->gfx.glupdates) {
         vc->gfx.glupdates = 0;
-        gtk_egl_set_scanout_mode(vc, false);
         gd_egl_draw(vc);
     }
 }
diff --git a/ui/gtk-gl-area.c b/ui/gtk-gl-area.c
index 2c9a0db42571..53d81124f211 100644
--- a/ui/gtk-gl-area.c
+++ b/ui/gtk-gl-area.c
@@ -148,7 +148,6 @@ void gd_gl_area_refresh(DisplayChangeListener *dcl)
 
     if (vc->gfx.glupdates) {
         vc->gfx.glupdates = 0;
-        gtk_gl_area_set_scanout_mode(vc, false);
         gtk_gl_area_queue_render(GTK_GL_AREA(vc->gfx.drawing_area));
     }
 }
-- 
2.47.1

[PATCH v6 08/10] docs/system: virtio-gpu: Add link to Mesa VirGL doc

[Dmitry Osipenko]

Extend virtio-gpu documentation with a link to the Mesa VirGL
documentation.

Suggested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 docs/system/devices/virtio-gpu.rst | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst
index f20c60016376..f8963c1f13cf 100644
--- a/docs/system/devices/virtio-gpu.rst
+++ b/docs/system/devices/virtio-gpu.rst
@@ -59,7 +59,7 @@ on typical modern Linux distributions.
 virtio-gpu virglrenderer
 ------------------------
 
-When using virgl accelerated graphics mode in the guest, OpenGL API calls
+When using `virgl`_ accelerated graphics mode in the guest, OpenGL API calls
 are translated into an intermediate representation (see `Gallium3D`_). The
 intermediate representation is communicated to the host and the
 `virglrenderer`_ library on the host translates the intermediate
@@ -68,6 +68,7 @@ representation back to OpenGL API calls.
 .. parsed-literal::
     -device virtio-gpu-gl
 
+.. _virgl: https://docs.mesa3d.org/drivers/virgl.html
 .. _Gallium3D: https://www.freedesktop.org/wiki/Software/gallium/
 .. _virglrenderer: https://gitlab.freedesktop.org/virgl/virglrenderer/
 
-- 
2.47.1

[PATCH v6 09/10] docs/system: virtio-gpu: Update Venus link

[Dmitry Osipenko]

Change virtio-gpu Venus link, pointing it at the Mesa Venus
documentation instead of the protocol. The Mesa doc provides more
information and also has a link to the protocol.

Suggested-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
---
 docs/system/devices/virtio-gpu.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst
index f8963c1f13cf..ea3eb052df3c 100644
--- a/docs/system/devices/virtio-gpu.rst
+++ b/docs/system/devices/virtio-gpu.rst
@@ -81,7 +81,7 @@ of virtio-gpu host memory window. This is typically between 256M and 8G.
 .. parsed-literal::
     -device virtio-gpu-gl,hostmem=8G,blob=true,venus=true
 
-.. _venus: https://gitlab.freedesktop.org/virgl/venus-protocol/
+.. _venus: https://docs.mesa3d.org/drivers/venus.html
 
 DRM native context is supported since release of `virglrenderer`_ v1.0.0
 using `drm`_ protocol.  ``DRM`` virtio-gpu capability set ("capset") requires
-- 
2.47.1

[PATCH v6 10/10] docs/system: virtio-gpu: Document host/guest requirements

[Dmitry Osipenko]

From: Alex Bennée <alex.bennee@linaro.org>

This attempts to tidy up the VirtIO GPU documentation to make the list
of requirements clearer. There are still a lot of moving parts and the
distros have some catching up to do before this is all handled
automatically.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Cc: Sergio Lopez Pascual <slp@redhat.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
[dmitry.osipenko@collabora.com: Extended and corrected doc]
---
 docs/system/devices/virtio-gpu.rst | 107 ++++++++++++++++++++++++++++-
 1 file changed, 106 insertions(+), 1 deletion(-)

diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst
index ea3eb052df3c..b3db984ff2d3 100644
--- a/docs/system/devices/virtio-gpu.rst
+++ b/docs/system/devices/virtio-gpu.rst
@@ -5,7 +5,9 @@ virtio-gpu
 ==========
 
 This document explains the setup and usage of the virtio-gpu device.
-The virtio-gpu device paravirtualizes the GPU and display controller.
+The virtio-gpu device provides a GPU and display controller
+paravirtualized using VirtIO. It supports a number of different modes
+from simple 2D displays to fully accelerated 3D graphics.
 
 Linux kernel support
 --------------------
@@ -13,6 +15,24 @@ Linux kernel support
 virtio-gpu requires a guest Linux kernel built with the
 ``CONFIG_DRM_VIRTIO_GPU`` option.
 
+Dependencies
+............
+
+.. note::
+  GPU virtualisation is still an evolving field. Depending on the mode
+  you are running you may need to override distribution supplied
+  libraries with more recent versions or enable build options.
+
+  Depending on the mode there are a number of requirements the host must
+  meet to be able to be able to support guests. For 3D acceleration QEMU
+  must be able to access the hosts GPU and for the best performance be
+  able to reliably share GPU memory with the guest.
+
+  Virtio-gpu requires a guest Linux kernel built with the
+  ``CONFIG_DRM_VIRTIO_GPU`` option. For 3D accelerations you
+  will need support from guest Mesa configured for whichever encapsulation
+  you need.
+
 QEMU virtio-gpu variants
 ------------------------
 
@@ -56,6 +76,16 @@ on typical modern Linux distributions.
 .. _Mesa: https://www.mesa3d.org/
 .. _SwiftShader: https://github.com/google/swiftshader
 
+.. list-table:: Host Requirements
+  :header-rows: 1
+
+  * - Mode
+    - Kernel
+    - Userspace
+  * - virtio-gpu
+    - Framebuffer enabled
+    - GTK or SDL display
+
 virtio-gpu virglrenderer
 ------------------------
 
@@ -94,6 +124,61 @@ of virtio-gpu host memory window. This is typically between 256M and 8G.
 
 .. _drm: https://gitlab.freedesktop.org/virgl/virglrenderer/-/tree/main/src/drm
 
+.. list-table:: Host Requirements
+  :header-rows: 1
+
+  * - Mode
+    - Kernel
+    - Userspace
+  * - virtio-gpu-gl (OpenGL pass-through)
+    - GPU enabled
+    - libvirglrenderer (virgl support)
+  * - virtio-gpu-gl (Vulkan pass-through)
+    - Linux 6.13+
+    - libvirglrenderer (>= 1.0.0, venus support)
+  * - virtio-gpu-gl (vDRM native context/AMD)
+    - Linux 6.13+
+    - libvirglrenderer (>= 1.1.0, DRM renderer support)
+  * - virtio-gpu-gl (vDRM native context/Freedreno)
+    - Linux 6.4+
+    - libvirglrenderer (>= 1.0.0, DRM renderer support)
+  * - virtio-gpu-gl (vDRM native context/Intel i915)
+    - Linux 6.13+
+    - libvirglrenderer (`mr1384`_, DRM renderer support)
+  * - virtio-gpu-gl (vDRM native context/Asahi)
+    - Linux 6.13+
+    - libvirglrenderer (`mr1274`_, DRM renderer support)
+
+.. _mr1384: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384
+.. _mr1274: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1274
+
+.. list-table:: Guest Requirements
+  :header-rows: 1
+
+  * - Mode
+    - Mesa Version
+    - Mesa build flags
+  * - virtio-gpu-gl (OpenGL pass-through)
+    - 20.3.0+
+    - -Dgallium-drivers=virgl
+  * - virtio-gpu-gl (Vulkan pass-through)
+    - 24.2.0+
+    - -Dvulkan-drivers=virtio
+  * - virtio-gpu-gl (vDRM native context/AMD)
+    - 25.0.0+
+    - -Dgallium-drivers=radeonsi -Dvulkan-drivers=amd -Damdgpu-virtio=true
+  * - virtio-gpu-gl (vDRM native context/Freedreno)
+    - 23.1.0+
+    - -Dgallium-drivers=freedreno -Dvulkan-drivers=freedreno
+  * - virtio-gpu-gl (vDRM native context/Intel i915)
+    - `mr29870`_
+    - -Dgallium-drivers=iris -Dvulkan-drivers=intel -Dintel-virtio-experimental=true
+  * - virtio-gpu-gl (vDRM native context/Asahi)
+    - 24.2.0+
+    - -Dgallium-drivers=asahi -Dvulkan-drivers=asahi
+
+.. _mr29870: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870
+
 virtio-gpu rutabaga
 -------------------
 
@@ -133,3 +218,23 @@ Surfaceless is the default if ``wsi`` is not specified.
 .. _Wayland display passthrough: https://www.youtube.com/watch?v=OZJiHMtIQ2M
 .. _gfxstream-enabled rutabaga: https://crosvm.dev/book/appendix/rutabaga_gfx.html
 .. _guest Wayland proxy: https://crosvm.dev/book/devices/wayland.html
+
+.. list-table:: Host Requirements
+  :header-rows: 1
+
+  * - Mode
+    - Kernel
+    - Userspace
+  * - virtio-gpu-gl (rutabaga/gfxstream)
+    - GPU enabled
+    - aemu/rutabaga_gfx_ffi or vhost-user client with support
+
+.. list-table:: Guest Requirements
+  :header-rows: 1
+
+  * - Mode
+    - Mesa Version
+    - Mesa build flags
+  * - virtio-gpu-gl (rutabaga/gfxstream)
+    - 24.3.0+
+    - -Dvulkan-drivers=gfxstream
-- 
2.47.1

Re: [PATCH v6 10/10] docs/system: virtio-gpu: Document host/guest requirements

[Akihiko Odaki]

On 2025/01/27 5:11, Dmitry Osipenko wrote:
> From: Alex Bennée <alex.bennee@linaro.org>
> 
> This attempts to tidy up the VirtIO GPU documentation to make the list
> of requirements clearer. There are still a lot of moving parts and the
> distros have some catching up to do before this is all handled
> automatically.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Sergio Lopez Pascual <slp@redhat.com>
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> [dmitry.osipenko@collabora.com: Extended and corrected doc]
> ---
>   docs/system/devices/virtio-gpu.rst | 107 ++++++++++++++++++++++++++++-
>   1 file changed, 106 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/system/devices/virtio-gpu.rst b/docs/system/devices/virtio-gpu.rst
> index ea3eb052df3c..b3db984ff2d3 100644
> --- a/docs/system/devices/virtio-gpu.rst
> +++ b/docs/system/devices/virtio-gpu.rst
> @@ -5,7 +5,9 @@ virtio-gpu
>   ==========
>   
>   This document explains the setup and usage of the virtio-gpu device.
> -The virtio-gpu device paravirtualizes the GPU and display controller.
> +The virtio-gpu device provides a GPU and display controller
> +paravirtualized using VirtIO. It supports a number of different modes
> +from simple 2D displays to fully accelerated 3D graphics.
>   
>   Linux kernel support
>   --------------------
> @@ -13,6 +15,24 @@ Linux kernel support
>   virtio-gpu requires a guest Linux kernel built with the
>   ``CONFIG_DRM_VIRTIO_GPU`` option.
>   
> +Dependencies
> +............
> +
> +.. note::
> +  GPU virtualisation is still an evolving field. Depending on the mode
> +  you are running you may need to override distribution supplied
> +  libraries with more recent versions or enable build options.

s/virtualisation/virtualization/ for consistency with other documentations.

> +
> +  Depending on the mode there are a number of requirements the host must
> +  meet to be able to be able to support guests. For 3D acceleration QEMU
> +  must be able to access the hosts GPU and for the best performance be
> +  able to reliably share GPU memory with the guest.
> +
> +  Virtio-gpu requires a guest Linux kernel built with the
> +  ``CONFIG_DRM_VIRTIO_GPU`` option. For 3D accelerations you
> +  will need support from guest Mesa configured for whichever encapsulation
> +  you need.

This section is part of the "Linux kernel support" chapter, which used 
to describe the guest Linux kernel requirement, but this section 
discusses a broader topic that includes the host requirements and guest 
Mesa. This section needs to be re-structured.

It says "GPU virtualisation is still an evolving field", but I believe 
the main evolving field is 3D acceleration. The later parts also 
repetitively mention 3D acceleration. Instead of repeating the same 
phrase, let the reader know that this section talks about 3D 
acceleration at the beginning. It will make the section more concise and 
allows readers to skip it when they do not care 3D acceleration.

The ``CONFIG_DRM_VIRTIO_GPU`` option is already described earlier so its 
description is redundant.

> +
>   QEMU virtio-gpu variants
>   ------------------------
>   
> @@ -56,6 +76,16 @@ on typical modern Linux distributions.
>   .. _Mesa: https://www.mesa3d.org/
>   .. _SwiftShader: https://github.com/google/swiftshader
>   
> +.. list-table:: Host Requirements
> +  :header-rows: 1
> +
> +  * - Mode
> +    - Kernel
> +    - Userspace
> +  * - virtio-gpu
> +    - Framebuffer enabled

It is not clear what "framebuffer enabled" means, and it is also 
inconsistent with the host requirements tables in later sections that 
describes the Linux kernel version. Also be aware that virtio-gpu works 
effectively anywhere, not just Linux.

> +    - GTK or SDL display

It is also inconsistent with later section that describes acceleration 
backends instead of the display. virtio-gpu also works with any display 
and is not restricted to GTK or SDL.

> +
>   virtio-gpu virglrenderer
>   ------------------------
>   
> @@ -94,6 +124,61 @@ of virtio-gpu host memory window. This is typically between 256M and 8G.
>   
>   .. _drm: https://gitlab.freedesktop.org/virgl/virglrenderer/-/tree/main/src/drm
>   
> +.. list-table:: Host Requirements
> +  :header-rows: 1
> +
> +  * - Mode
> +    - Kernel
> +    - Userspace
> +  * - virtio-gpu-gl (OpenGL pass-through)

It's already in the "virtio-gpu virglrenderer" setion so you don't have 
to mention "virtio-gpu-gl" again here.

> +    - GPU enabled> +    - libvirglrenderer (virgl support)> +  * - virtio-gpu-gl (Vulkan 
pass-through)
> +    - Linux 6.13+
> +    - libvirglrenderer (>= 1.0.0, venus support)

"venus support" is a vague wording. I can guess it means it requires a 
build flag, but it's not clear for a novice.

Perhaps you may write the build flag as you did for Mesa.

> +  * - virtio-gpu-gl (vDRM native context/AMD)

The later part of documentation calls it "DRM native context", not "vDRM 
native context"; let's keep them consistent. "vDRM native context" seems 
rarely used; I could only find one example of existing literature:
https://www.collabora.com/news-and-blog/blog/2025/01/15/the-state-of-gfx-virtualization-using-virglrenderer/

Mesa has a directory named vdrm but it is mentioned in no user-facing 
documentation.

> +    - Linux 6.13+
> +    - libvirglrenderer (>= 1.1.0, DRM renderer support)
> +  * - virtio-gpu-gl (vDRM native context/Freedreno)
> +    - Linux 6.4+
> +    - libvirglrenderer (>= 1.0.0, DRM renderer support)
> +  * - virtio-gpu-gl (vDRM native context/Intel i915)
> +    - Linux 6.13+
> +    - libvirglrenderer (`mr1384`_, DRM renderer support)
> +  * - virtio-gpu-gl (vDRM native context/Asahi)
> +    - Linux 6.13+
> +    - libvirglrenderer (`mr1274`_, DRM renderer support)
> +
> +.. _mr1384: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384
> +.. _mr1274: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1274
 > +> +.. list-table:: Guest Requirements
> +  :header-rows: 1
> +
> +  * - Mode
> +    - Mesa Version
> +    - Mesa build flags
> +  * - virtio-gpu-gl (OpenGL pass-through)
> +    - 20.3.0+
> +    - -Dgallium-drivers=virgl
> +  * - virtio-gpu-gl (Vulkan pass-through)
> +    - 24.2.0+
> +    - -Dvulkan-drivers=virtio
> +  * - virtio-gpu-gl (vDRM native context/AMD)
> +    - 25.0.0+
> +    - -Dgallium-drivers=radeonsi -Dvulkan-drivers=amd -Damdgpu-virtio=true
> +  * - virtio-gpu-gl (vDRM native context/Freedreno)
> +    - 23.1.0+
> +    - -Dgallium-drivers=freedreno -Dvulkan-drivers=freedreno
> +  * - virtio-gpu-gl (vDRM native context/Intel i915)
> +    - `mr29870`_
> +    - -Dgallium-drivers=iris -Dvulkan-drivers=intel -Dintel-virtio-experimental=true
> +  * - virtio-gpu-gl (vDRM native context/Asahi)
> +    - 24.2.0+
> +    - -Dgallium-drivers=asahi -Dvulkan-drivers=asahi
> +
> +.. _mr29870: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870
> +
>   virtio-gpu rutabaga
>   -------------------
>   
> @@ -133,3 +218,23 @@ Surfaceless is the default if ``wsi`` is not specified.
>   .. _Wayland display passthrough: https://www.youtube.com/watch?v=OZJiHMtIQ2M
>   .. _gfxstream-enabled rutabaga: https://crosvm.dev/book/appendix/rutabaga_gfx.html
>   .. _guest Wayland proxy: https://crosvm.dev/book/devices/wayland.html
> +
> +.. list-table:: Host Requirements
> +  :header-rows: 1
> +
> +  * - Mode
> +    - Kernel
> +    - Userspace
> +  * - virtio-gpu-gl (rutabaga/gfxstream)
> +    - GPU enabled
> +    - aemu/rutabaga_gfx_ffi or vhost-user client with support

Let's omit the mention of aemu. It is a dependency of rutabaga_gfx_ffi 
and referring to dependencies of our dependencies will make the 
documentation too cluttered. Users should also see rutabaga_gfx_ffi 
needs aemu anyway in its build guide; the reference of aemu here is 
effectively redundant.

I don't see the vhost-user support in Rutabaga. Does it really exist?

> +
> +.. list-table:: Guest Requirements
> +  :header-rows: 1
> +
> +  * - Mode
> +    - Mesa Version
> +    - Mesa build flags
> +  * - virtio-gpu-gl (rutabaga/gfxstream)
> +    - 24.3.0+
> +    - -Dvulkan-drivers=gfxstream

Re: [PATCH v6 10/10] docs/system: virtio-gpu: Document host/guest requirements

[Alex Bennée]

Akihiko Odaki <akihiko.odaki@daynix.com> writes:

> On 2025/01/27 5:11, Dmitry Osipenko wrote:
>> From: Alex Bennée <alex.bennee@linaro.org>
>> This attempts to tidy up the VirtIO GPU documentation to make the
>> list
>> of requirements clearer. There are still a lot of moving parts and the
>> distros have some catching up to do before this is all handled
>> automatically.
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> Cc: Sergio Lopez Pascual <slp@redhat.com>
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>> [dmitry.osipenko@collabora.com: Extended and corrected doc]
<snip>
>>   virtio-gpu rutabaga
>>   -------------------
>>   @@ -133,3 +218,23 @@ Surfaceless is the default if ``wsi`` is not
>> specified.
>>   .. _Wayland display passthrough: https://www.youtube.com/watch?v=OZJiHMtIQ2M
>>   .. _gfxstream-enabled rutabaga: https://crosvm.dev/book/appendix/rutabaga_gfx.html
>>   .. _guest Wayland proxy: https://crosvm.dev/book/devices/wayland.html
>> +
>> +.. list-table:: Host Requirements
>> +  :header-rows: 1
>> +
>> +  * - Mode
>> +    - Kernel
>> +    - Userspace
>> +  * - virtio-gpu-gl (rutabaga/gfxstream)
>> +    - GPU enabled
>> +    - aemu/rutabaga_gfx_ffi or vhost-user client with support
>
> Let's omit the mention of aemu. It is a dependency of rutabaga_gfx_ffi
> and referring to dependencies of our dependencies will make the
> documentation too cluttered. Users should also see rutabaga_gfx_ffi
> needs aemu anyway in its build guide; the reference of aemu here is
> effectively redundant.
>
> I don't see the vhost-user support in Rutabaga. Does it really exist?

vhost-device-gpu supports gfxstream although the 3D acceleration parts
of that are still WIP:

  https://github.com/rust-vmm/vhost-device/tree/main/staging/vhost-device-gpu

>
>> +
>> +.. list-table:: Guest Requirements
>> +  :header-rows: 1
>> +
>> +  * - Mode
>> +    - Mesa Version
>> +    - Mesa build flags
>> +  * - virtio-gpu-gl (rutabaga/gfxstream)
>> +    - 24.3.0+
>> +    - -Dvulkan-drivers=gfxstream

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v6 10/10] docs/system: virtio-gpu: Document host/guest requirements

[Akihiko Odaki]

On 2025/01/27 18:45, Alex Bennée wrote:
> Akihiko Odaki <akihiko.odaki@daynix.com> writes:
> 
>> On 2025/01/27 5:11, Dmitry Osipenko wrote:
>>> From: Alex Bennée <alex.bennee@linaro.org>
>>> This attempts to tidy up the VirtIO GPU documentation to make the
>>> list
>>> of requirements clearer. There are still a lot of moving parts and the
>>> distros have some catching up to do before this is all handled
>>> automatically.
>>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>>> Cc: Sergio Lopez Pascual <slp@redhat.com>
>>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>>> [dmitry.osipenko@collabora.com: Extended and corrected doc]
> <snip>
>>>    virtio-gpu rutabaga
>>>    -------------------
>>>    @@ -133,3 +218,23 @@ Surfaceless is the default if ``wsi`` is not
>>> specified.
>>>    .. _Wayland display passthrough: https://www.youtube.com/watch?v=OZJiHMtIQ2M
>>>    .. _gfxstream-enabled rutabaga: https://crosvm.dev/book/appendix/rutabaga_gfx.html
>>>    .. _guest Wayland proxy: https://crosvm.dev/book/devices/wayland.html
>>> +
>>> +.. list-table:: Host Requirements
>>> +  :header-rows: 1
>>> +
>>> +  * - Mode
>>> +    - Kernel
>>> +    - Userspace
>>> +  * - virtio-gpu-gl (rutabaga/gfxstream)
>>> +    - GPU enabled
>>> +    - aemu/rutabaga_gfx_ffi or vhost-user client with support
>>
>> Let's omit the mention of aemu. It is a dependency of rutabaga_gfx_ffi
>> and referring to dependencies of our dependencies will make the
>> documentation too cluttered. Users should also see rutabaga_gfx_ffi
>> needs aemu anyway in its build guide; the reference of aemu here is
>> effectively redundant.
>>
>> I don't see the vhost-user support in Rutabaga. Does it really exist?
> 
> vhost-device-gpu supports gfxstream although the 3D acceleration parts
> of that are still WIP:
> 
>    https://github.com/rust-vmm/vhost-device/tree/main/staging/vhost-device-gpu

It is nice to know the project.

vhost-user support is implemented with virtio-gpu-gl but it has its own 
device variant so it is not a right place to describe it. vhost-user-gpu 
is not documented at all so if you are going to write its documentation 
it will be a great addition.

> 
>>
>>> +
>>> +.. list-table:: Guest Requirements
>>> +  :header-rows: 1
>>> +
>>> +  * - Mode
>>> +    - Mesa Version
>>> +    - Mesa build flags
>>> +  * - virtio-gpu-gl (rutabaga/gfxstream)
>>> +    - 24.3.0+
>>> +    - -Dvulkan-drivers=gfxstream
> 

Re: [PATCH v6 10/10] docs/system: virtio-gpu: Document host/guest requirements

[Dmitry Osipenko]

On 1/27/25 09:28, Akihiko Odaki wrote:
...

Thanks for the doc review! Will improve the patch in the next iteration.

-- 
Best regards,
Dmitry

Re: [PATCH v6 10/10] docs/system: virtio-gpu: Document host/guest requirements

[Gurchetan Singh]

[-- Attachment #1: Type: text/plain, Size: 6215 bytes --]

On Sun, Jan 26, 2025 at 12:14 PM Dmitry Osipenko <
dmitry.osipenko@collabora.com> wrote:

> From: Alex Bennée <alex.bennee@linaro.org>
>
> This attempts to tidy up the VirtIO GPU documentation to make the list
> of requirements clearer. There are still a lot of moving parts and the
> distros have some catching up to do before this is all handled
> automatically.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Cc: Sergio Lopez Pascual <slp@redhat.com>
> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> [dmitry.osipenko@collabora.com: Extended and corrected doc]
> ---
>  docs/system/devices/virtio-gpu.rst | 107 ++++++++++++++++++++++++++++-
>  1 file changed, 106 insertions(+), 1 deletion(-)
>
> diff --git a/docs/system/devices/virtio-gpu.rst
> b/docs/system/devices/virtio-gpu.rst
> index ea3eb052df3c..b3db984ff2d3 100644
> --- a/docs/system/devices/virtio-gpu.rst
> +++ b/docs/system/devices/virtio-gpu.rst
> @@ -5,7 +5,9 @@ virtio-gpu
>  ==========
>
>  This document explains the setup and usage of the virtio-gpu device.
> -The virtio-gpu device paravirtualizes the GPU and display controller.
> +The virtio-gpu device provides a GPU and display controller
> +paravirtualized using VirtIO. It supports a number of different modes
> +from simple 2D displays to fully accelerated 3D graphics.
>
>  Linux kernel support
>  --------------------
> @@ -13,6 +15,24 @@ Linux kernel support
>  virtio-gpu requires a guest Linux kernel built with the
>  ``CONFIG_DRM_VIRTIO_GPU`` option.
>
> +Dependencies
> +............
> +
> +.. note::
> +  GPU virtualisation is still an evolving field. Depending on the mode
> +  you are running you may need to override distribution supplied
> +  libraries with more recent versions or enable build options.
> +
> +  Depending on the mode there are a number of requirements the host must
> +  meet to be able to be able to support guests. For 3D acceleration QEMU
> +  must be able to access the hosts GPU and for the best performance be
> +  able to reliably share GPU memory with the guest.
> +
> +  Virtio-gpu requires a guest Linux kernel built with the
> +  ``CONFIG_DRM_VIRTIO_GPU`` option. For 3D accelerations you
> +  will need support from guest Mesa configured for whichever encapsulation
> +  you need.
> +
>  QEMU virtio-gpu variants
>  ------------------------
>
> @@ -56,6 +76,16 @@ on typical modern Linux distributions.
>  .. _Mesa: https://www.mesa3d.org/
>  .. _SwiftShader: https://github.com/google/swiftshader
>
> +.. list-table:: Host Requirements
> +  :header-rows: 1
> +
> +  * - Mode
> +    - Kernel
> +    - Userspace
> +  * - virtio-gpu
> +    - Framebuffer enabled
> +    - GTK or SDL display
> +
>  virtio-gpu virglrenderer
>  ------------------------
>
> @@ -94,6 +124,61 @@ of virtio-gpu host memory window. This is typically
> between 256M and 8G.
>
>  .. _drm:
> https://gitlab.freedesktop.org/virgl/virglrenderer/-/tree/main/src/drm
>
> +.. list-table:: Host Requirements
> +  :header-rows: 1
> +
> +  * - Mode
> +    - Kernel
> +    - Userspace
> +  * - virtio-gpu-gl (OpenGL pass-through)
> +    - GPU enabled
> +    - libvirglrenderer (virgl support)
> +  * - virtio-gpu-gl (Vulkan pass-through)
> +    - Linux 6.13+
> +    - libvirglrenderer (>= 1.0.0, venus support)
> +  * - virtio-gpu-gl (vDRM native context/AMD)
> +    - Linux 6.13+
> +    - libvirglrenderer (>= 1.1.0, DRM renderer support)
> +  * - virtio-gpu-gl (vDRM native context/Freedreno)
> +    - Linux 6.4+
> +    - libvirglrenderer (>= 1.0.0, DRM renderer support)
> +  * - virtio-gpu-gl (vDRM native context/Intel i915)
> +    - Linux 6.13+
> +    - libvirglrenderer (`mr1384`_, DRM renderer support)
> +  * - virtio-gpu-gl (vDRM native context/Asahi)
> +    - Linux 6.13+
> +    - libvirglrenderer (`mr1274`_, DRM renderer support)
> +
> +.. _mr1384:
> https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384
> +.. _mr1274:
> https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1274
> +
> +.. list-table:: Guest Requirements
> +  :header-rows: 1
> +
> +  * - Mode
> +    - Mesa Version
> +    - Mesa build flags
> +  * - virtio-gpu-gl (OpenGL pass-through)
> +    - 20.3.0+
> +    - -Dgallium-drivers=virgl
> +  * - virtio-gpu-gl (Vulkan pass-through)
> +    - 24.2.0+
> +    - -Dvulkan-drivers=virtio
> +  * - virtio-gpu-gl (vDRM native context/AMD)
> +    - 25.0.0+
> +    - -Dgallium-drivers=radeonsi -Dvulkan-drivers=amd -Damdgpu-virtio=true
> +  * - virtio-gpu-gl (vDRM native context/Freedreno)
> +    - 23.1.0+
> +    - -Dgallium-drivers=freedreno -Dvulkan-drivers=freedreno
> +  * - virtio-gpu-gl (vDRM native context/Intel i915)
> +    - `mr29870`_
> +    - -Dgallium-drivers=iris -Dvulkan-drivers=intel
> -Dintel-virtio-experimental=true
> +  * - virtio-gpu-gl (vDRM native context/Asahi)
> +    - 24.2.0+
> +    - -Dgallium-drivers=asahi -Dvulkan-drivers=asahi
> +
> +.. _mr29870:
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870
> +
>  virtio-gpu rutabaga
>  -------------------
>
> @@ -133,3 +218,23 @@ Surfaceless is the default if ``wsi`` is not
> specified.
>  .. _Wayland display passthrough:
> https://www.youtube.com/watch?v=OZJiHMtIQ2M
>  .. _gfxstream-enabled rutabaga:
> https://crosvm.dev/book/appendix/rutabaga_gfx.html
>  .. _guest Wayland proxy: https://crosvm.dev/book/devices/wayland.html
> +
> +.. list-table:: Host Requirements
> +  :header-rows: 1
> +
> +  * - Mode
> +    - Kernel
> +    - Userspace
> +  * - virtio-gpu-gl (rutabaga/gfxstream)
> +    - GPU enabled
> +    - aemu/rutabaga_gfx_ffi or vhost-user client with support
> +
> +.. list-table:: Guest Requirements
> +  :header-rows: 1
> +
> +  * - Mode
> +    - Mesa Version
> +    - Mesa build flags
> +  * - virtio-gpu-gl (rutabaga/gfxstream)
>

Shouldn't this be `virtio-gpu-rutabaga` instead of `virtio-gpu-gl`?  If
we're including WiP MRs, can we include Magma too??

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33190



> +    - 24.3.0+
> +    - -Dvulkan-drivers=gfxstream
> --
> 2.47.1
>
>

[-- Attachment #2: Type: text/html, Size: 8516 bytes --]

Re: [PATCH v6 10/10] docs/system: virtio-gpu: Document host/guest requirements

[Dmitry Osipenko]

On 1/29/25 04:18, Gurchetan Singh wrote:
> On Sun, Jan 26, 2025 at 12:14 PM Dmitry Osipenko <
> dmitry.osipenko@collabora.com> wrote:
> 
>> From: Alex Bennée <alex.bennee@linaro.org>
>>
>> This attempts to tidy up the VirtIO GPU documentation to make the list
>> of requirements clearer. There are still a lot of moving parts and the
>> distros have some catching up to do before this is all handled
>> automatically.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> Cc: Sergio Lopez Pascual <slp@redhat.com>
>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>> [dmitry.osipenko@collabora.com: Extended and corrected doc]
>> ---
>>  docs/system/devices/virtio-gpu.rst | 107 ++++++++++++++++++++++++++++-
>>  1 file changed, 106 insertions(+), 1 deletion(-)
>>
>> diff --git a/docs/system/devices/virtio-gpu.rst
>> b/docs/system/devices/virtio-gpu.rst
>> index ea3eb052df3c..b3db984ff2d3 100644
>> --- a/docs/system/devices/virtio-gpu.rst
>> +++ b/docs/system/devices/virtio-gpu.rst
>> @@ -5,7 +5,9 @@ virtio-gpu
>>  ==========
>>
>>  This document explains the setup and usage of the virtio-gpu device.
>> -The virtio-gpu device paravirtualizes the GPU and display controller.
>> +The virtio-gpu device provides a GPU and display controller
>> +paravirtualized using VirtIO. It supports a number of different modes
>> +from simple 2D displays to fully accelerated 3D graphics.
>>
>>  Linux kernel support
>>  --------------------
>> @@ -13,6 +15,24 @@ Linux kernel support
>>  virtio-gpu requires a guest Linux kernel built with the
>>  ``CONFIG_DRM_VIRTIO_GPU`` option.
>>
>> +Dependencies
>> +............
>> +
>> +.. note::
>> +  GPU virtualisation is still an evolving field. Depending on the mode
>> +  you are running you may need to override distribution supplied
>> +  libraries with more recent versions or enable build options.
>> +
>> +  Depending on the mode there are a number of requirements the host must
>> +  meet to be able to be able to support guests. For 3D acceleration QEMU
>> +  must be able to access the hosts GPU and for the best performance be
>> +  able to reliably share GPU memory with the guest.
>> +
>> +  Virtio-gpu requires a guest Linux kernel built with the
>> +  ``CONFIG_DRM_VIRTIO_GPU`` option. For 3D accelerations you
>> +  will need support from guest Mesa configured for whichever encapsulation
>> +  you need.
>> +
>>  QEMU virtio-gpu variants
>>  ------------------------
>>
>> @@ -56,6 +76,16 @@ on typical modern Linux distributions.
>>  .. _Mesa: https://www.mesa3d.org/
>>  .. _SwiftShader: https://github.com/google/swiftshader
>>
>> +.. list-table:: Host Requirements
>> +  :header-rows: 1
>> +
>> +  * - Mode
>> +    - Kernel
>> +    - Userspace
>> +  * - virtio-gpu
>> +    - Framebuffer enabled
>> +    - GTK or SDL display
>> +
>>  virtio-gpu virglrenderer
>>  ------------------------
>>
>> @@ -94,6 +124,61 @@ of virtio-gpu host memory window. This is typically
>> between 256M and 8G.
>>
>>  .. _drm:
>> https://gitlab.freedesktop.org/virgl/virglrenderer/-/tree/main/src/drm
>>
>> +.. list-table:: Host Requirements
>> +  :header-rows: 1
>> +
>> +  * - Mode
>> +    - Kernel
>> +    - Userspace
>> +  * - virtio-gpu-gl (OpenGL pass-through)
>> +    - GPU enabled
>> +    - libvirglrenderer (virgl support)
>> +  * - virtio-gpu-gl (Vulkan pass-through)
>> +    - Linux 6.13+
>> +    - libvirglrenderer (>= 1.0.0, venus support)
>> +  * - virtio-gpu-gl (vDRM native context/AMD)
>> +    - Linux 6.13+
>> +    - libvirglrenderer (>= 1.1.0, DRM renderer support)
>> +  * - virtio-gpu-gl (vDRM native context/Freedreno)
>> +    - Linux 6.4+
>> +    - libvirglrenderer (>= 1.0.0, DRM renderer support)
>> +  * - virtio-gpu-gl (vDRM native context/Intel i915)
>> +    - Linux 6.13+
>> +    - libvirglrenderer (`mr1384`_, DRM renderer support)
>> +  * - virtio-gpu-gl (vDRM native context/Asahi)
>> +    - Linux 6.13+
>> +    - libvirglrenderer (`mr1274`_, DRM renderer support)
>> +
>> +.. _mr1384:
>> https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384
>> +.. _mr1274:
>> https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1274
>> +
>> +.. list-table:: Guest Requirements
>> +  :header-rows: 1
>> +
>> +  * - Mode
>> +    - Mesa Version
>> +    - Mesa build flags
>> +  * - virtio-gpu-gl (OpenGL pass-through)
>> +    - 20.3.0+
>> +    - -Dgallium-drivers=virgl
>> +  * - virtio-gpu-gl (Vulkan pass-through)
>> +    - 24.2.0+
>> +    - -Dvulkan-drivers=virtio
>> +  * - virtio-gpu-gl (vDRM native context/AMD)
>> +    - 25.0.0+
>> +    - -Dgallium-drivers=radeonsi -Dvulkan-drivers=amd -Damdgpu-virtio=true
>> +  * - virtio-gpu-gl (vDRM native context/Freedreno)
>> +    - 23.1.0+
>> +    - -Dgallium-drivers=freedreno -Dvulkan-drivers=freedreno
>> +  * - virtio-gpu-gl (vDRM native context/Intel i915)
>> +    - `mr29870`_
>> +    - -Dgallium-drivers=iris -Dvulkan-drivers=intel
>> -Dintel-virtio-experimental=true
>> +  * - virtio-gpu-gl (vDRM native context/Asahi)
>> +    - 24.2.0+
>> +    - -Dgallium-drivers=asahi -Dvulkan-drivers=asahi
>> +
>> +.. _mr29870:
>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870
>> +
>>  virtio-gpu rutabaga
>>  -------------------
>>
>> @@ -133,3 +218,23 @@ Surfaceless is the default if ``wsi`` is not
>> specified.
>>  .. _Wayland display passthrough:
>> https://www.youtube.com/watch?v=OZJiHMtIQ2M
>>  .. _gfxstream-enabled rutabaga:
>> https://crosvm.dev/book/appendix/rutabaga_gfx.html
>>  .. _guest Wayland proxy: https://crosvm.dev/book/devices/wayland.html
>> +
>> +.. list-table:: Host Requirements
>> +  :header-rows: 1
>> +
>> +  * - Mode
>> +    - Kernel
>> +    - Userspace
>> +  * - virtio-gpu-gl (rutabaga/gfxstream)
>> +    - GPU enabled
>> +    - aemu/rutabaga_gfx_ffi or vhost-user client with support
>> +
>> +.. list-table:: Guest Requirements
>> +  :header-rows: 1
>> +
>> +  * - Mode
>> +    - Mesa Version
>> +    - Mesa build flags
>> +  * - virtio-gpu-gl (rutabaga/gfxstream)
>>
> 
> Shouldn't this be `virtio-gpu-rutabaga` instead of `virtio-gpu-gl`?  If
> we're including WiP MRs, can we include Magma too??
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33190

Indeed, will correct it. And add the link. Thanks!

-- 
Best regards,
Dmitry

Re: [PATCH v6 10/10] docs/system: virtio-gpu: Document host/guest requirements

[Dmitry Osipenko]

On 1/31/25 20:19, Dmitry Osipenko wrote:
> On 1/29/25 04:18, Gurchetan Singh wrote:
>> On Sun, Jan 26, 2025 at 12:14 PM Dmitry Osipenko <
>> dmitry.osipenko@collabora.com> wrote:
>>
>>> From: Alex Bennée <alex.bennee@linaro.org>
>>>
>>> This attempts to tidy up the VirtIO GPU documentation to make the list
>>> of requirements clearer. There are still a lot of moving parts and the
>>> distros have some catching up to do before this is all handled
>>> automatically.
>>>
>>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>>> Cc: Sergio Lopez Pascual <slp@redhat.com>
>>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>>> [dmitry.osipenko@collabora.com: Extended and corrected doc]
>>> ---
>>>  docs/system/devices/virtio-gpu.rst | 107 ++++++++++++++++++++++++++++-
>>>  1 file changed, 106 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/docs/system/devices/virtio-gpu.rst
>>> b/docs/system/devices/virtio-gpu.rst
>>> index ea3eb052df3c..b3db984ff2d3 100644
>>> --- a/docs/system/devices/virtio-gpu.rst
>>> +++ b/docs/system/devices/virtio-gpu.rst
>>> @@ -5,7 +5,9 @@ virtio-gpu
>>>  ==========
>>>
>>>  This document explains the setup and usage of the virtio-gpu device.
>>> -The virtio-gpu device paravirtualizes the GPU and display controller.
>>> +The virtio-gpu device provides a GPU and display controller
>>> +paravirtualized using VirtIO. It supports a number of different modes
>>> +from simple 2D displays to fully accelerated 3D graphics.
>>>
>>>  Linux kernel support
>>>  --------------------
>>> @@ -13,6 +15,24 @@ Linux kernel support
>>>  virtio-gpu requires a guest Linux kernel built with the
>>>  ``CONFIG_DRM_VIRTIO_GPU`` option.
>>>
>>> +Dependencies
>>> +............
>>> +
>>> +.. note::
>>> +  GPU virtualisation is still an evolving field. Depending on the mode
>>> +  you are running you may need to override distribution supplied
>>> +  libraries with more recent versions or enable build options.
>>> +
>>> +  Depending on the mode there are a number of requirements the host must
>>> +  meet to be able to be able to support guests. For 3D acceleration QEMU
>>> +  must be able to access the hosts GPU and for the best performance be
>>> +  able to reliably share GPU memory with the guest.
>>> +
>>> +  Virtio-gpu requires a guest Linux kernel built with the
>>> +  ``CONFIG_DRM_VIRTIO_GPU`` option. For 3D accelerations you
>>> +  will need support from guest Mesa configured for whichever encapsulation
>>> +  you need.
>>> +
>>>  QEMU virtio-gpu variants
>>>  ------------------------
>>>
>>> @@ -56,6 +76,16 @@ on typical modern Linux distributions.
>>>  .. _Mesa: https://www.mesa3d.org/
>>>  .. _SwiftShader: https://github.com/google/swiftshader
>>>
>>> +.. list-table:: Host Requirements
>>> +  :header-rows: 1
>>> +
>>> +  * - Mode
>>> +    - Kernel
>>> +    - Userspace
>>> +  * - virtio-gpu
>>> +    - Framebuffer enabled
>>> +    - GTK or SDL display
>>> +
>>>  virtio-gpu virglrenderer
>>>  ------------------------
>>>
>>> @@ -94,6 +124,61 @@ of virtio-gpu host memory window. This is typically
>>> between 256M and 8G.
>>>
>>>  .. _drm:
>>> https://gitlab.freedesktop.org/virgl/virglrenderer/-/tree/main/src/drm
>>>
>>> +.. list-table:: Host Requirements
>>> +  :header-rows: 1
>>> +
>>> +  * - Mode
>>> +    - Kernel
>>> +    - Userspace
>>> +  * - virtio-gpu-gl (OpenGL pass-through)
>>> +    - GPU enabled
>>> +    - libvirglrenderer (virgl support)
>>> +  * - virtio-gpu-gl (Vulkan pass-through)
>>> +    - Linux 6.13+
>>> +    - libvirglrenderer (>= 1.0.0, venus support)
>>> +  * - virtio-gpu-gl (vDRM native context/AMD)
>>> +    - Linux 6.13+
>>> +    - libvirglrenderer (>= 1.1.0, DRM renderer support)
>>> +  * - virtio-gpu-gl (vDRM native context/Freedreno)
>>> +    - Linux 6.4+
>>> +    - libvirglrenderer (>= 1.0.0, DRM renderer support)
>>> +  * - virtio-gpu-gl (vDRM native context/Intel i915)
>>> +    - Linux 6.13+
>>> +    - libvirglrenderer (`mr1384`_, DRM renderer support)
>>> +  * - virtio-gpu-gl (vDRM native context/Asahi)
>>> +    - Linux 6.13+
>>> +    - libvirglrenderer (`mr1274`_, DRM renderer support)
>>> +
>>> +.. _mr1384:
>>> https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384
>>> +.. _mr1274:
>>> https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1274
>>> +
>>> +.. list-table:: Guest Requirements
>>> +  :header-rows: 1
>>> +
>>> +  * - Mode
>>> +    - Mesa Version
>>> +    - Mesa build flags
>>> +  * - virtio-gpu-gl (OpenGL pass-through)
>>> +    - 20.3.0+
>>> +    - -Dgallium-drivers=virgl
>>> +  * - virtio-gpu-gl (Vulkan pass-through)
>>> +    - 24.2.0+
>>> +    - -Dvulkan-drivers=virtio
>>> +  * - virtio-gpu-gl (vDRM native context/AMD)
>>> +    - 25.0.0+
>>> +    - -Dgallium-drivers=radeonsi -Dvulkan-drivers=amd -Damdgpu-virtio=true
>>> +  * - virtio-gpu-gl (vDRM native context/Freedreno)
>>> +    - 23.1.0+
>>> +    - -Dgallium-drivers=freedreno -Dvulkan-drivers=freedreno
>>> +  * - virtio-gpu-gl (vDRM native context/Intel i915)
>>> +    - `mr29870`_
>>> +    - -Dgallium-drivers=iris -Dvulkan-drivers=intel
>>> -Dintel-virtio-experimental=true
>>> +  * - virtio-gpu-gl (vDRM native context/Asahi)
>>> +    - 24.2.0+
>>> +    - -Dgallium-drivers=asahi -Dvulkan-drivers=asahi
>>> +
>>> +.. _mr29870:
>>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870
>>> +
>>>  virtio-gpu rutabaga
>>>  -------------------
>>>
>>> @@ -133,3 +218,23 @@ Surfaceless is the default if ``wsi`` is not
>>> specified.
>>>  .. _Wayland display passthrough:
>>> https://www.youtube.com/watch?v=OZJiHMtIQ2M
>>>  .. _gfxstream-enabled rutabaga:
>>> https://crosvm.dev/book/appendix/rutabaga_gfx.html
>>>  .. _guest Wayland proxy: https://crosvm.dev/book/devices/wayland.html
>>> +
>>> +.. list-table:: Host Requirements
>>> +  :header-rows: 1
>>> +
>>> +  * - Mode
>>> +    - Kernel
>>> +    - Userspace
>>> +  * - virtio-gpu-gl (rutabaga/gfxstream)
>>> +    - GPU enabled
>>> +    - aemu/rutabaga_gfx_ffi or vhost-user client with support
>>> +
>>> +.. list-table:: Guest Requirements
>>> +  :header-rows: 1
>>> +
>>> +  * - Mode
>>> +    - Mesa Version
>>> +    - Mesa build flags
>>> +  * - virtio-gpu-gl (rutabaga/gfxstream)
>>>
>>
>> Shouldn't this be `virtio-gpu-rutabaga` instead of `virtio-gpu-gl`?  If
>> we're including WiP MRs, can we include Magma too??
>>
>> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33190
> 
> Indeed, will correct it. And add the link. Thanks!

RE the link. virtio-gpu-rutabaga doesn't support gfxstream-magma capset,
hence I see no place to add the link. We are adding links to supported
features only here. For the magma link should be added once
virtio-gpu-rutabaga will support it, like it was done for venus and now
for nctx capsets.

-- 
Best regards,
Dmitry

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Alex Bennée]

Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:

> This patchset adds DRM native context support to VirtIO-GPU on Qemu.
>
> Contarary to Virgl and Venus contexts that mediates high level GFX APIs,
> DRM native context [1] mediates lower level kernel driver UAPI, which
> reflects in a less CPU overhead and less/simpler code needed to support it.
> DRM context consists of a host and guest parts that have to be implemented
> for each GPU driver. On a guest side, DRM context presents a virtual GPU as
> a real/native host GPU device for GL/VK applications.
>
> [1] https://www.youtube.com/watch?v=9sFP_yddLLQ
>
> Today there are four DRM native context drivers existing in a wild:
>
>   - Freedreno (Qualcomm SoC GPUs), completely upstreamed
>   - AMDGPU, completely upstreamed

Well good news and bad news.

I can verify that AMD native context works when I run my Aarch64 guest
on my Aarch64 host with -accel TCG (therefor avoiding KVM all together).
I get potato frame rates though (~150FPS) although I suspect that is
because the PCI errata workaround.

When it comes to graphics memory allocation is there anything I can do
to force all allocations to be very aligned? Is this in the purview of
the AMD drm drivers or TTM itself?

I'm still seeing corruption with -display gtk,gl=on on my x86 system
BTW. I would like to understand if that is a problem with QEMU, GTK or
something else in the stack before we merge.

>   - Intel (i915), merge requests are opened
>   - Asahi (Apple SoC GPUs), partially merged upstream
>
<snip>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Dmitry Osipenko]

On 1/27/25 19:17, Alex Bennée wrote:
> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
> 
>> This patchset adds DRM native context support to VirtIO-GPU on Qemu.
>>
>> Contarary to Virgl and Venus contexts that mediates high level GFX APIs,
>> DRM native context [1] mediates lower level kernel driver UAPI, which
>> reflects in a less CPU overhead and less/simpler code needed to support it.
>> DRM context consists of a host and guest parts that have to be implemented
>> for each GPU driver. On a guest side, DRM context presents a virtual GPU as
>> a real/native host GPU device for GL/VK applications.
>>
>> [1] https://www.youtube.com/watch?v=9sFP_yddLLQ
>>
>> Today there are four DRM native context drivers existing in a wild:
>>
>>   - Freedreno (Qualcomm SoC GPUs), completely upstreamed
>>   - AMDGPU, completely upstreamed
> 
> Well good news and bad news.
> 
> I can verify that AMD native context works when I run my Aarch64 guest
> on my Aarch64 host with -accel TCG (therefor avoiding KVM all together).
> I get potato frame rates though (~150FPS) although I suspect that is
> because the PCI errata workaround.
> 
> When it comes to graphics memory allocation is there anything I can do
> to force all allocations to be very aligned? Is this in the purview of
> the AMD drm drivers or TTM itself?

All GPU allocations should be aligned to a page size. Alignment is
specified by AMD driver. I don't expect that alignment is the problem.
What's the size of your host and guest pages?

-- 
Best regards,
Dmitry

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Alex Bennée]

Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:

> On 1/27/25 19:17, Alex Bennée wrote:
>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>> 
>>> This patchset adds DRM native context support to VirtIO-GPU on Qemu.
>>>
>>> Contarary to Virgl and Venus contexts that mediates high level GFX APIs,
>>> DRM native context [1] mediates lower level kernel driver UAPI, which
>>> reflects in a less CPU overhead and less/simpler code needed to support it.
>>> DRM context consists of a host and guest parts that have to be implemented
>>> for each GPU driver. On a guest side, DRM context presents a virtual GPU as
>>> a real/native host GPU device for GL/VK applications.
>>>
>>> [1] https://www.youtube.com/watch?v=9sFP_yddLLQ
>>>
>>> Today there are four DRM native context drivers existing in a wild:
>>>
>>>   - Freedreno (Qualcomm SoC GPUs), completely upstreamed
>>>   - AMDGPU, completely upstreamed
>> 
>> Well good news and bad news.
>> 
>> I can verify that AMD native context works when I run my Aarch64 guest
>> on my Aarch64 host with -accel TCG (therefor avoiding KVM all together).
>> I get potato frame rates though (~150FPS) although I suspect that is
>> because the PCI errata workaround.
>> 
>> When it comes to graphics memory allocation is there anything I can do
>> to force all allocations to be very aligned? Is this in the purview of
>> the AMD drm drivers or TTM itself?
>
> All GPU allocations should be aligned to a page size. Alignment is
> specified by AMD driver. I don't expect that alignment is the problem.
> What's the size of your host and guest pages?

4k AFAIK.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Dmitry Osipenko]

On 1/27/25 19:17, Alex Bennée wrote:
...
> I'm still seeing corruption with -display gtk,gl=on on my x86 system
> BTW. I would like to understand if that is a problem with QEMU, GTK or
> something else in the stack before we merge.

I reproduced the display mirroring/corruption issue and bisected it to
the following commit. The problem only happens when QEMU/GTK uses
Wayland display directly, while previously I was running QEMU with
XWayland that doesn't have the problem. Why this change breaks dmabuf
displaying with Wayland/GTK is unclear. Reverting commit fixes the bug.

+Dongwon Kim +Vivek Kasireddy

commit 77bf310084dad38b3a2badf01766c659056f1cf2
Author: Dongwon Kim <dongwon.kim@intel.com>
Date:   Fri Apr 26 15:50:59 2024 -0700

    ui/gtk: Draw guest frame at refresh cycle

    Draw routine needs to be manually invoked in the next refresh
    if there is a scanout blob from the guest. This is to prevent
    a situation where there is a scheduled draw event but it won't
    happen bacause the window is currently in inactive state
    (minimized or tabified). If draw is not done for a long time,
    gl_block timeout and/or fence timeout (on the guest) will happen
    eventually.

    v2: Use gd_gl_area_draw(vc) in gtk-gl-area.c

    Suggested-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
    Cc: Gerd Hoffmann <kraxel@redhat.com>
    Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
    Cc: Daniel P. Berrangé <berrange@redhat.com>
    Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
    Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
    Message-Id: <20240426225059.3871283-1-dongwon.kim@intel.com>

-- 
Best regards,
Dmitry

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Alex Bennée]

Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:

> On 1/27/25 19:17, Alex Bennée wrote:
> ...
>> I'm still seeing corruption with -display gtk,gl=on on my x86 system
>> BTW. I would like to understand if that is a problem with QEMU, GTK or
>> something else in the stack before we merge.
>
> I reproduced the display mirroring/corruption issue and bisected it to
> the following commit. The problem only happens when QEMU/GTK uses
> Wayland display directly, while previously I was running QEMU with
> XWayland that doesn't have the problem. Why this change breaks dmabuf
> displaying with Wayland/GTK is unclear.

Ahh that makes sense - I obviously forgot to mention I'm running
sway/wayland across both machines.

> Reverting commit fixes the bug.
>
> +Dongwon Kim +Vivek Kasireddy
>
> commit 77bf310084dad38b3a2badf01766c659056f1cf2
> Author: Dongwon Kim <dongwon.kim@intel.com>
> Date:   Fri Apr 26 15:50:59 2024 -0700
>
>     ui/gtk: Draw guest frame at refresh cycle
>
>     Draw routine needs to be manually invoked in the next refresh
>     if there is a scanout blob from the guest. This is to prevent
>     a situation where there is a scheduled draw event but it won't
>     happen bacause the window is currently in inactive state
>     (minimized or tabified). If draw is not done for a long time,
>     gl_block timeout and/or fence timeout (on the guest) will happen
>     eventually.
>
>     v2: Use gd_gl_area_draw(vc) in gtk-gl-area.c
>
>     Suggested-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
>     Cc: Gerd Hoffmann <kraxel@redhat.com>
>     Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
>     Cc: Daniel P. Berrangé <berrange@redhat.com>
>     Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
>     Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
>     Message-Id: <20240426225059.3871283-1-dongwon.kim@intel.com>


Maybe a race on:

    QemuDmaBuf *dmabuf = vc->gfx.guest_fb.dmabuf;
?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

RE: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Kim, Dongwon]

Hi,

The commit below could change the timing of drawing by making the drawing
done at refresh cycle instead of via drawing event. So it looks like either dmabuf
or client's framebuffer is being written and read at the same time. Hey, can you
describe how the corruption looks like? Is it just garbage image with random noise
or the actual frame with some defects like tearing...?  

> Subject: Re: [PATCH v6 00/10] Support virtio-gpu DRM native context
> 
> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
> 
> > On 1/27/25 19:17, Alex Bennée wrote:
> > ...
> >> I'm still seeing corruption with -display gtk,gl=on on my x86 system
> >> BTW. I would like to understand if that is a problem with QEMU, GTK
> >> or something else in the stack before we merge.
> >
> > I reproduced the display mirroring/corruption issue and bisected it to
> > the following commit. The problem only happens when QEMU/GTK uses
> > Wayland display directly, while previously I was running QEMU with
> > XWayland that doesn't have the problem. Why this change breaks dmabuf
> > displaying with Wayland/GTK is unclear.
> 
> Ahh that makes sense - I obviously forgot to mention I'm running sway/wayland
> across both machines.
> 
> > Reverting commit fixes the bug.
> >
> > +Dongwon Kim +Vivek Kasireddy
> >
> > commit 77bf310084dad38b3a2badf01766c659056f1cf2
> > Author: Dongwon Kim <dongwon.kim@intel.com>
> > Date:   Fri Apr 26 15:50:59 2024 -0700
> >
> >     ui/gtk: Draw guest frame at refresh cycle
> >
> >     Draw routine needs to be manually invoked in the next refresh
> >     if there is a scanout blob from the guest. This is to prevent
> >     a situation where there is a scheduled draw event but it won't
> >     happen bacause the window is currently in inactive state
> >     (minimized or tabified). If draw is not done for a long time,
> >     gl_block timeout and/or fence timeout (on the guest) will happen
> >     eventually.
> >
> >     v2: Use gd_gl_area_draw(vc) in gtk-gl-area.c
> >
> >     Suggested-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> >     Cc: Gerd Hoffmann <kraxel@redhat.com>
> >     Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
> >     Cc: Daniel P. Berrangé <berrange@redhat.com>
> >     Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
> >     Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> >     Message-Id: <20240426225059.3871283-1-dongwon.kim@intel.com>
> 
> 
> Maybe a race on:
> 
>     QemuDmaBuf *dmabuf = vc->gfx.guest_fb.dmabuf; ?
> 
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Alex Bennée]

"Kim, Dongwon" <dongwon.kim@intel.com> writes:

> Hi,
>
> The commit below could change the timing of drawing by making the drawing
> done at refresh cycle instead of via drawing event. So it looks like either dmabuf
> or client's framebuffer is being written and read at the same time. Hey, can you
> describe how the corruption looks like? Is it just garbage image with random noise
> or the actual frame with some defects like tearing...?

The terminal gets mirrored upside down and the mouse creates damage as
it moves about.

>
>> Subject: Re: [PATCH v6 00/10] Support virtio-gpu DRM native context
>> 
>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>> 
>> > On 1/27/25 19:17, Alex Bennée wrote:
>> > ...
>> >> I'm still seeing corruption with -display gtk,gl=on on my x86 system
>> >> BTW. I would like to understand if that is a problem with QEMU, GTK
>> >> or something else in the stack before we merge.
>> >
>> > I reproduced the display mirroring/corruption issue and bisected it to
>> > the following commit. The problem only happens when QEMU/GTK uses
>> > Wayland display directly, while previously I was running QEMU with
>> > XWayland that doesn't have the problem. Why this change breaks dmabuf
>> > displaying with Wayland/GTK is unclear.
>> 
>> Ahh that makes sense - I obviously forgot to mention I'm running sway/wayland
>> across both machines.
>> 
>> > Reverting commit fixes the bug.
>> >
>> > +Dongwon Kim +Vivek Kasireddy
>> >
>> > commit 77bf310084dad38b3a2badf01766c659056f1cf2
>> > Author: Dongwon Kim <dongwon.kim@intel.com>
>> > Date:   Fri Apr 26 15:50:59 2024 -0700
>> >
>> >     ui/gtk: Draw guest frame at refresh cycle
>> >
>> >     Draw routine needs to be manually invoked in the next refresh
>> >     if there is a scanout blob from the guest. This is to prevent
>> >     a situation where there is a scheduled draw event but it won't
>> >     happen bacause the window is currently in inactive state
>> >     (minimized or tabified). If draw is not done for a long time,
>> >     gl_block timeout and/or fence timeout (on the guest) will happen
>> >     eventually.
>> >
>> >     v2: Use gd_gl_area_draw(vc) in gtk-gl-area.c
>> >
>> >     Suggested-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
>> >     Cc: Gerd Hoffmann <kraxel@redhat.com>
>> >     Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
>> >     Cc: Daniel P. Berrangé <berrange@redhat.com>
>> >     Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
>> >     Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
>> >     Message-Id: <20240426225059.3871283-1-dongwon.kim@intel.com>
>> 
>> 
>> Maybe a race on:
>> 
>>     QemuDmaBuf *dmabuf = vc->gfx.guest_fb.dmabuf; ?
>> 
>> --
>> Alex Bennée
>> Virtualisation Tech Lead @ Linaro

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

RE: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Kim, Dongwon]

> Subject: Re: [PATCH v6 00/10] Support virtio-gpu DRM native context
> 
> "Kim, Dongwon" <dongwon.kim@intel.com> writes:
> 
> > Hi,
> >
> > The commit below could change the timing of drawing by making the
> > drawing done at refresh cycle instead of via drawing event. So it
> > looks like either dmabuf or client's framebuffer is being written and
> > read at the same time. Hey, can you describe how the corruption looks
> > like? Is it just garbage image with random noise or the actual frame with some
> defects like tearing...?
> 
> The terminal gets mirrored upside down and the mouse creates damage as it
> moves about.

I am wondering if this is reproducible without virgl and drm native context (like w/
sw rasterizer on the guest) as well. 

> 
> >
> >> Subject: Re: [PATCH v6 00/10] Support virtio-gpu DRM native context
> >>
> >> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
> >>
> >> > On 1/27/25 19:17, Alex Bennée wrote:
> >> > ...
> >> >> I'm still seeing corruption with -display gtk,gl=on on my x86
> >> >> system BTW. I would like to understand if that is a problem with
> >> >> QEMU, GTK or something else in the stack before we merge.
> >> >
> >> > I reproduced the display mirroring/corruption issue and bisected it
> >> > to the following commit. The problem only happens when QEMU/GTK
> >> > uses Wayland display directly, while previously I was running QEMU
> >> > with XWayland that doesn't have the problem. Why this change breaks
> >> > dmabuf displaying with Wayland/GTK is unclear.
> >>
> >> Ahh that makes sense - I obviously forgot to mention I'm running
> >> sway/wayland across both machines.
> >>
> >> > Reverting commit fixes the bug.
> >> >
> >> > +Dongwon Kim +Vivek Kasireddy
> >> >
> >> > commit 77bf310084dad38b3a2badf01766c659056f1cf2
> >> > Author: Dongwon Kim <dongwon.kim@intel.com>
> >> > Date:   Fri Apr 26 15:50:59 2024 -0700
> >> >
> >> >     ui/gtk: Draw guest frame at refresh cycle
> >> >
> >> >     Draw routine needs to be manually invoked in the next refresh
> >> >     if there is a scanout blob from the guest. This is to prevent
> >> >     a situation where there is a scheduled draw event but it won't
> >> >     happen bacause the window is currently in inactive state
> >> >     (minimized or tabified). If draw is not done for a long time,
> >> >     gl_block timeout and/or fence timeout (on the guest) will happen
> >> >     eventually.
> >> >
> >> >     v2: Use gd_gl_area_draw(vc) in gtk-gl-area.c
> >> >
> >> >     Suggested-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> >> >     Cc: Gerd Hoffmann <kraxel@redhat.com>
> >> >     Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
> >> >     Cc: Daniel P. Berrangé <berrange@redhat.com>
> >> >     Signed-off-by: Dongwon Kim <dongwon.kim@intel.com>
> >> >     Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> >> >     Message-Id: <20240426225059.3871283-1-dongwon.kim@intel.com>
> >>
> >>
> >> Maybe a race on:
> >>
> >>     QemuDmaBuf *dmabuf = vc->gfx.guest_fb.dmabuf; ?
> >>
> >> --
> >> Alex Bennée
> >> Virtualisation Tech Lead @ Linaro
> 
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Dmitry Osipenko]

On 2/4/25 04:51, Kim, Dongwon wrote:
>> Subject: Re: [PATCH v6 00/10] Support virtio-gpu DRM native context
>>
>> "Kim, Dongwon" <dongwon.kim@intel.com> writes:
>>
>>> Hi,
>>>
>>> The commit below could change the timing of drawing by making the
>>> drawing done at refresh cycle instead of via drawing event. So it
>>> looks like either dmabuf or client's framebuffer is being written and
>>> read at the same time. Hey, can you describe how the corruption looks
>>> like? Is it just garbage image with random noise or the actual frame with some
>> defects like tearing...?
>>
>> The terminal gets mirrored upside down and the mouse creates damage as it
>> moves about.
> 
> I am wondering if this is reproducible without virgl and drm native context (like w/
> sw rasterizer on the guest) as well. 

It looks like a problem with redraw areas, see video sample [1].

[1]
https://drive.google.com/file/d/13PN2sFoPsM2ox6_gf9GLXStbsZ27xlLy/view?usp=sharing

It's reproducible without native context with a SW render using '-device
virtio-vga,hostmem=8G,blob=on'

-- 
Best regards,
Dmitry

RE: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Kim, Dongwon]

Thanks for showing me the video. I will take a look and check what would go wrong here. I kinda understand corruption may happen
in some scenario but I don't know what could cause the upside down image. Do you have any idea?? Maybe the frame was temporarily replaced with
a mishandled texture that QEMU creates from the surface temporarily but I am not sure..

In the worst case scenario, I think we may have to revert the change from gtk-gl-area.c for now until the problem is root-caused.
But you would see some rendering timeout in case the GTK window is in invisible state (like minimization).

> Subject: Re: [PATCH v6 00/10] Support virtio-gpu DRM native context
> 
> On 2/4/25 04:51, Kim, Dongwon wrote:
> >> Subject: Re: [PATCH v6 00/10] Support virtio-gpu DRM native context
> >>
> >> "Kim, Dongwon" <dongwon.kim@intel.com> writes:
> >>
> >>> Hi,
> >>>
> >>> The commit below could change the timing of drawing by making the
> >>> drawing done at refresh cycle instead of via drawing event. So it
> >>> looks like either dmabuf or client's framebuffer is being written
> >>> and read at the same time. Hey, can you describe how the corruption
> >>> looks like? Is it just garbage image with random noise or the actual
> >>> frame with some
> >> defects like tearing...?
> >>
> >> The terminal gets mirrored upside down and the mouse creates damage
> >> as it moves about.
> >
> > I am wondering if this is reproducible without virgl and drm native
> > context (like w/ sw rasterizer on the guest) as well.
> 
> It looks like a problem with redraw areas, see video sample [1].
> 
> [1]
> https://drive.google.com/file/d/13PN2sFoPsM2ox6_gf9GLXStbsZ27xlLy/view?u
> sp=sharing
> 
> It's reproducible without native context with a SW render using '-device virtio-
> vga,hostmem=8G,blob=on'
> 
> --
> Best regards,
> Dmitry

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Dmitry Osipenko]

On 2/5/25 21:53, Kim, Dongwon wrote:
> Thanks for showing me the video. I will take a look and check what would go wrong here. I kinda understand corruption may happen
> in some scenario but I don't know what could cause the upside down image. Do you have any idea?? Maybe the frame was temporarily replaced with
> a mishandled texture that QEMU creates from the surface temporarily but I am not sure..

No clue. Could be anything. Could be a GTK/Wayland bug, could be an
obscure QEMU bug. GTK expert wanted here.

> In the worst case scenario, I think we may have to revert the change from gtk-gl-area.c for now until the problem is root-caused.

Good to me

> But you would see some rendering timeout in case the GTK window is in invisible state (like minimization).

No timeouts observed

-- 
Best regards,
Dmitry

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Dmitry Osipenko]

On 2/5/25 23:08, Dmitry Osipenko wrote:
>> Thanks for showing me the video. I will take a look and check what would go wrong here. I kinda understand corruption may happen
>> in some scenario but I don't know what could cause the upside down image. Do you have any idea?? Maybe the frame was temporarily replaced with
>> a mishandled texture that QEMU creates from the surface temporarily but I am not sure..
> No clue. Could be anything. Could be a GTK/Wayland bug, could be an
> obscure QEMU bug. GTK expert wanted here.

Alright, it's bugged with "blob=on", but works with "blob=off". While I
don't see QEMU using blobs. Might be QEMU's bug then.

-- 
Best regards,
Dmitry

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Dmitry Osipenko]

On 2/6/25 01:13, Dmitry Osipenko wrote:
> On 2/5/25 23:08, Dmitry Osipenko wrote:
>>> Thanks for showing me the video. I will take a look and check what would go wrong here. I kinda understand corruption may happen
>>> in some scenario but I don't know what could cause the upside down image. Do you have any idea?? Maybe the frame was temporarily replaced with
>>> a mishandled texture that QEMU creates from the surface temporarily but I am not sure..
>> No clue. Could be anything. Could be a GTK/Wayland bug, could be an
>> obscure QEMU bug. GTK expert wanted here.
> 
> Alright, it's bugged with "blob=on", but works with "blob=off". While I
> don't see QEMU using blobs. Might be QEMU's bug then.
> 

Looked further at it. So QEMU was using blobs with "blob=on" and I was
looking at a wrong place. Then I found that setting y0_top=true for
dmabuf makes display to show upside down, but there is no rendering bug
with it. Something redraws display with y0_top=true, while it should be
y0_top=false. I couldn't figure out how it's related to the offending
change.

I also noticed that QEMU checks Wayland presence in
early_gtk_display_init() and doesn't use EGL callbacks that are used for
X11 display, but the y0_top logic looks the same. Interestingly, Windows
should be using same display code paths as Wayland, but I don't have
ability to test Windows.

If nobody will be able to fix the bug soon, at least reverting the
Wayland part will be good to do.

-- 
Best regards,
Dmitry

RE: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Kasireddy, Vivek]

Hi Dmitry,

> Subject: Re: [PATCH v6 00/10] Support virtio-gpu DRM native context
> 
> On 2/6/25 01:13, Dmitry Osipenko wrote:
> > On 2/5/25 23:08, Dmitry Osipenko wrote:
> >>> Thanks for showing me the video. I will take a look and check what would
> go wrong here. I kinda understand corruption may happen
> >>> in some scenario but I don't know what could cause the upside down
> image. Do you have any idea?? Maybe the frame was temporarily replaced
> with
> >>> a mishandled texture that QEMU creates from the surface temporarily but
> I am not sure..
> >> No clue. Could be anything. Could be a GTK/Wayland bug, could be an
> >> obscure QEMU bug. GTK expert wanted here.
> >
> > Alright, it's bugged with "blob=on", but works with "blob=off". While I
> > don't see QEMU using blobs. Might be QEMU's bug then.
> >
> 
> Looked further at it. So QEMU was using blobs with "blob=on" and I was
> looking at a wrong place. Then I found that setting y0_top=true for
> dmabuf makes display to show upside down, but there is no rendering bug
> with it. Something redraws display with y0_top=true, while it should be
> y0_top=false. I couldn't figure out how it's related to the offending
> change.
It is possible that the additional draw call (offending change) is exposing a bug
elsewhere. This is because having both blob=on and virgl=on was not a valid combo
until recently. IIUC, virgl directly calls gd_gl_area_scanout_texture() with y0_top=true
(sometimes) but I guess gd_gl_area_scanout_texture() might be getting called again
with yo_top=false via gd_gl_area_scanout_dmabuf() in the same repaint cycle?

> 
> I also noticed that QEMU checks Wayland presence in
> early_gtk_display_init() and doesn't use EGL callbacks that are used for
> X11 display, but the y0_top logic looks the same. Interestingly, Windows
> should be using same display code paths as Wayland, but I don't have
> ability to test Windows.
> 
> If nobody will be able to fix the bug soon, at least reverting the
> Wayland part will be good to do.
Hope we can find a proper fix soon but looks like Dongwon already sent the patch
to revert the changes in gtk-gl-area.c.

Thanks,
Vivek

> 
> --
> Best regards,
> Dmitry

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Alex Bennée]

Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:

> This patchset adds DRM native context support to VirtIO-GPU on Qemu.
>
> Contarary to Virgl and Venus contexts that mediates high level GFX APIs,
> DRM native context [1] mediates lower level kernel driver UAPI, which
> reflects in a less CPU overhead and less/simpler code needed to support it.
> DRM context consists of a host and guest parts that have to be implemented
> for each GPU driver. On a guest side, DRM context presents a virtual GPU as
> a real/native host GPU device for GL/VK applications.
>
<snip>

So first the good news. I can now get this up and running (x86/kvm guest
with Intel graphics) and as far as I can tell the native context mode is
working. With Dongwon Kim's patch the mirroring/corruption I was seeing
is gone.

I can successfully run glmark2-wayland (although see bellow) but vkmark
completely fails to start reporting:

  MESA: info: virtgpu backend not enabling VIRTGPU_PARAM_CREATE_FENCE_PASSING
  MESA: info: virtgpu backend not enabling VIRTGPU_PARAM_CREATE_GUEST_HANDLE
  MESA: error: DRM_IOCTL_VIRTGPU_GET_CAPS failed with Invalid argument
  MESA: error: DRM_IOCTL_VIRTGPU_CONTEXT_INIT failed with Invalid argument, continuing without context...
  MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with No space left on device
  MESA: error: Failed to create virtgpu AddressSpaceStream
  MESA: error: vulkan: Failed to get host connection
  MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with No space left on device
  MESA: error: Failed to create virtgpu AddressSpaceStream
  MESA: error: vulkan: Failed to get host connection
  MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with No space left on device
  MESA: error: Failed to create virtgpu AddressSpaceStream
  MESA: error: vulkan: Failed to get host connection
  MESA: warning: ../src/gfxstream/guest/vulkan/gfxstream_vk_device.cpp:681: VK_ERROR_DEVICE_LOST
  MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with No space left on device
  MESA: error: Failed to create virtgpu AddressSpaceStream
  MESA: error: vulkan: Failed to get host connection
  MESA: warning: ../src/gfxstream/guest/vulkan/gfxstream_vk_device.cpp:332: VK_ERROR_DEVICE_LOST
  === Physical Device 0 ===
      Vendor ID:      0x8086
      Device ID:      0xA780
      Device Name:    Intel(R) Graphics (RPL-S)
      Driver Version: 101068899
      Device UUID:    b39e1cf39b101489e3c6039406f78d6c

I was booting with 4G of shared memory.

Later versions of vkmark (2025.01) fail due to missing the
VK_KHR_display extension required as of
https://github.com/vkmark/vkmark/commit/7c3189c6482cb84c3c0e69d6dabb9d80e0c0092a

> # Note about known performance problem in Qemu:
>
> DRM contexts are mapping host blobs extensively and these mapping
> operations work slowly in Qemu. Exact reason is unknown. Mappings work
> fast on Crosvm For DRM contexts this problem is more visible than for
> Venus/Virgl.

And how!

With drm_native I get a lot of stutter while running and barely 100FPS
(compared to ~8000 on pure venus). IMHO we need to figure out why there
is such a discrepancy before merging because currently it makes more
sense to use Venus. 

<snip>

I'll do some more testing with my AMD/Aarch64 rig next week.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Dmitry Osipenko]

On 2/14/25 17:33, Alex Bennée wrote:
> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
> 
>> This patchset adds DRM native context support to VirtIO-GPU on Qemu.
>>
>> Contarary to Virgl and Venus contexts that mediates high level GFX APIs,
>> DRM native context [1] mediates lower level kernel driver UAPI, which
>> reflects in a less CPU overhead and less/simpler code needed to support it.
>> DRM context consists of a host and guest parts that have to be implemented
>> for each GPU driver. On a guest side, DRM context presents a virtual GPU as
>> a real/native host GPU device for GL/VK applications.
>>
> <snip>
> 
> So first the good news. I can now get this up and running (x86/kvm guest
> with Intel graphics) and as far as I can tell the native context mode is
> working. With Dongwon Kim's patch the mirroring/corruption I was seeing
> is gone.
> 
> I can successfully run glmark2-wayland (although see bellow) but vkmark
> completely fails to start reporting:
> 
>   MESA: info: virtgpu backend not enabling VIRTGPU_PARAM_CREATE_FENCE_PASSING
>   MESA: info: virtgpu backend not enabling VIRTGPU_PARAM_CREATE_GUEST_HANDLE
>   MESA: error: DRM_IOCTL_VIRTGPU_GET_CAPS failed with Invalid argument
>   MESA: error: DRM_IOCTL_VIRTGPU_CONTEXT_INIT failed with Invalid argument, continuing without context...
>   MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with No space left on device
>   MESA: error: Failed to create virtgpu AddressSpaceStream
>   MESA: error: vulkan: Failed to get host connection
>   MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with No space left on device
>   MESA: error: Failed to create virtgpu AddressSpaceStream
>   MESA: error: vulkan: Failed to get host connection
>   MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with No space left on device
>   MESA: error: Failed to create virtgpu AddressSpaceStream
>   MESA: error: vulkan: Failed to get host connection
>   MESA: warning: ../src/gfxstream/guest/vulkan/gfxstream_vk_device.cpp:681: VK_ERROR_DEVICE_LOST
>   MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with No space left on device
>   MESA: error: Failed to create virtgpu AddressSpaceStream
>   MESA: error: vulkan: Failed to get host connection
>   MESA: warning: ../src/gfxstream/guest/vulkan/gfxstream_vk_device.cpp:332: VK_ERROR_DEVICE_LOST
>   === Physical Device 0 ===
>       Vendor ID:      0x8086
>       Device ID:      0xA780
>       Device Name:    Intel(R) Graphics (RPL-S)
>       Driver Version: 101068899
>       Device UUID:    b39e1cf39b101489e3c6039406f78d6c
> 
> I was booting with 4G of shared memory.

Thanks for the testing.

I assume all these errors are generated by the failing gfxstream. Hence,
may ignore them since you don't have enabled gfxstream.

> Later versions of vkmark (2025.01) fail due to missing the
> VK_KHR_display extension required as of
> https://github.com/vkmark/vkmark/commit/7c3189c6482cb84c3c0e69d6dabb9d80e0c0092a

This VK_KHR_display problem is only reproducible with your rootfs that
you shared with me. It could be a trouble with your build configs or a
buggy package version used by your rootfs build, more likely the former.

>> # Note about known performance problem in Qemu:
>>
>> DRM contexts are mapping host blobs extensively and these mapping
>> operations work slowly in Qemu. Exact reason is unknown. Mappings work
>> fast on Crosvm For DRM contexts this problem is more visible than for
>> Venus/Virgl.
> 
> And how!
> 
> With drm_native I get a lot of stutter while running and barely 100FPS
> (compared to ~8000 on pure venus). IMHO we need to figure out why there
> is such a discrepancy before merging because currently it makes more
> sense to use 
If you'd run with Xorg/Wayland directly without a DE, then it should
work okay. This should be a problem with unmapping performance that I'm
thinking about.

That unmapping problem is partially understood. Unmapping code works
correctly, but we'll need to optimize the flatview code to perform
unmapping immediately. Meanwhile, you may apply the QEMU hack below, it
should resolve most of the stutter, please let me know if it helps.

There is also a pending Mesa intel-virtio blob mapping optimization that
currently isn't available in my gitlab code, I'll refresh that feature
and then ask you to try it.

Could be that there is more to the unmapping perf issue in QEMU. I'm
investigating.

AMDGPU nctx is less affected by the bad unmapping performance. I expect
it will work well for you.



diff --git a/util/rcu.c b/util/rcu.c
index fa32c942e4bb..aac3522c323c 100644
--- a/util/rcu.c
+++ b/util/rcu.c
@@ -174,7 +174,7 @@ void synchronize_rcu(void)
 }


-#define RCU_CALL_MIN_SIZE        30
+#define RCU_CALL_MIN_SIZE        1

 /* Multi-producer, single-consumer queue based on urcu/static/wfqueue.h
  * from liburcu.  Note that head is only used by the consumer.
@@ -267,7 +267,7 @@ static void *call_rcu_thread(void *opaque)
          * added before synchronize_rcu() starts.
          */
         while (n == 0 || (n < RCU_CALL_MIN_SIZE && ++tries <= 5)) {
-            g_usleep(10000);
+            g_usleep(1000);
             if (n == 0) {
                 qemu_event_reset(&rcu_call_ready_event);
                 n = qatomic_read(&rcu_call_count);


-- 
Best regards,
Dmitry

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Alex Bennée]

Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:

> On 2/14/25 17:33, Alex Bennée wrote:
>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:
>> 
>>> This patchset adds DRM native context support to VirtIO-GPU on Qemu.
>>>
>>> Contarary to Virgl and Venus contexts that mediates high level GFX APIs,
>>> DRM native context [1] mediates lower level kernel driver UAPI, which
>>> reflects in a less CPU overhead and less/simpler code needed to support it.
>>> DRM context consists of a host and guest parts that have to be implemented
>>> for each GPU driver. On a guest side, DRM context presents a virtual GPU as
>>> a real/native host GPU device for GL/VK applications.
>>>
>> <snip>
>> 
>> So first the good news. I can now get this up and running (x86/kvm guest
>> with Intel graphics) and as far as I can tell the native context mode is
>> working. With Dongwon Kim's patch the mirroring/corruption I was seeing
>> is gone.
>> 
>> I can successfully run glmark2-wayland (although see bellow) but vkmark
>> completely fails to start reporting:
>> 
>>   MESA: info: virtgpu backend not enabling VIRTGPU_PARAM_CREATE_FENCE_PASSING
>>   MESA: info: virtgpu backend not enabling VIRTGPU_PARAM_CREATE_GUEST_HANDLE
>>   MESA: error: DRM_IOCTL_VIRTGPU_GET_CAPS failed with Invalid argument
>>   MESA: error: DRM_IOCTL_VIRTGPU_CONTEXT_INIT failed with Invalid argument, continuing without context...
>>   MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with No space left on device
>>   MESA: error: Failed to create virtgpu AddressSpaceStream
>>   MESA: error: vulkan: Failed to get host connection
>>   MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with No space left on device
>>   MESA: error: Failed to create virtgpu AddressSpaceStream
>>   MESA: error: vulkan: Failed to get host connection
>>   MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with No space left on device
>>   MESA: error: Failed to create virtgpu AddressSpaceStream
>>   MESA: error: vulkan: Failed to get host connection
>>   MESA: warning: ../src/gfxstream/guest/vulkan/gfxstream_vk_device.cpp:681: VK_ERROR_DEVICE_LOST
>>   MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with No space left on device
>>   MESA: error: Failed to create virtgpu AddressSpaceStream
>>   MESA: error: vulkan: Failed to get host connection
>>   MESA: warning: ../src/gfxstream/guest/vulkan/gfxstream_vk_device.cpp:332: VK_ERROR_DEVICE_LOST
>>   === Physical Device 0 ===
>>       Vendor ID:      0x8086
>>       Device ID:      0xA780
>>       Device Name:    Intel(R) Graphics (RPL-S)
>>       Driver Version: 101068899
>>       Device UUID:    b39e1cf39b101489e3c6039406f78d6c
>> 
>> I was booting with 4G of shared memory.
>
> Thanks for the testing.
>
> I assume all these errors are generated by the failing gfxstream. Hence,
> may ignore them since you don't have enabled gfxstream.
>
>> Later versions of vkmark (2025.01) fail due to missing the
>> VK_KHR_display extension required as of
>> https://github.com/vkmark/vkmark/commit/7c3189c6482cb84c3c0e69d6dabb9d80e0c0092a
>
> This VK_KHR_display problem is only reproducible with your rootfs that
> you shared with me. It could be a trouble with your build configs or a
> buggy package version used by your rootfs build, more likely the
> former.

So you have built that latest vkmark? This is a recent addition to
vkmark for the 2025.1 release.

Does vulkaninfo --summary show the extension available for you? It is
certainly available on the host side:

VK_KHR_display                         : extension revision 23

>>> # Note about known performance problem in Qemu:
>>>
>>> DRM contexts are mapping host blobs extensively and these mapping
>>> operations work slowly in Qemu. Exact reason is unknown. Mappings work
>>> fast on Crosvm For DRM contexts this problem is more visible than for
>>> Venus/Virgl.
>> 
>> And how!
>> 
>> With drm_native I get a lot of stutter while running and barely 100FPS
>> (compared to ~8000 on pure venus). IMHO we need to figure out why there
>> is such a discrepancy before merging because currently it makes more
>> sense to use 
> If you'd run with Xorg/Wayland directly without a DE, then it should
> work okay. This should be a problem with unmapping performance that I'm
> thinking about.
>
> That unmapping problem is partially understood. Unmapping code works
> correctly, but we'll need to optimize the flatview code to perform
> unmapping immediately.

Why immediately? Surely if we are unmapping we can defer it. Or is this
a case of having stale mappings making the life of new allocations
harder?

> Meanwhile, you may apply the QEMU hack below, it
> should resolve most of the stutter, please let me know if it helps.
>
> There is also a pending Mesa intel-virtio blob mapping optimization that
> currently isn't available in my gitlab code, I'll refresh that feature
> and then ask you to try it.
>
> Could be that there is more to the unmapping perf issue in QEMU. I'm
> investigating.
>
> AMDGPU nctx is less affected by the bad unmapping performance. I expect
> it will work well for you.
>
>
>
> diff --git a/util/rcu.c b/util/rcu.c
> index fa32c942e4bb..aac3522c323c 100644
> --- a/util/rcu.c
> +++ b/util/rcu.c
> @@ -174,7 +174,7 @@ void synchronize_rcu(void)
>  }
>
>
> -#define RCU_CALL_MIN_SIZE        30
> +#define RCU_CALL_MIN_SIZE        1
>
>  /* Multi-producer, single-consumer queue based on urcu/static/wfqueue.h
>   * from liburcu.  Note that head is only used by the consumer.
> @@ -267,7 +267,7 @@ static void *call_rcu_thread(void *opaque)
>           * added before synchronize_rcu() starts.
>           */
>          while (n == 0 || (n < RCU_CALL_MIN_SIZE && ++tries <= 5)) {
> -            g_usleep(10000);
> +            g_usleep(1000);
>              if (n == 0) {
>                  qemu_event_reset(&rcu_call_ready_event);
>                  n = qatomic_read(&rcu_call_count);

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Dmitry Osipenko]

On 2/17/25 18:22, Alex Bennée wrote:
...
>> This VK_KHR_display problem is only reproducible with your rootfs that
>> you shared with me. It could be a trouble with your build configs or a
>> buggy package version used by your rootfs build, more likely the
>> former.
> So you have built that latest vkmark? This is a recent addition to
> vkmark for the 2025.1 release.

Yes, latest 2025.1 from git/master.

> Does vulkaninfo --summary show the extension available for you? It is
> certainly available on the host side:
> 
> VK_KHR_display                         : extension revision 23
> 

Have it on guest with my rootfs, not with yours. I'd suspect problem is
with the your Mesa build flags, maybe you haven't enabled necessary
flags related to WSI.

..
>>> With drm_native I get a lot of stutter while running and barely 100FPS
>>> (compared to ~8000 on pure venus). IMHO we need to figure out why there
>>> is such a discrepancy before merging because currently it makes more
>>> sense to use 
>> If you'd run with Xorg/Wayland directly without a DE, then it should
>> work okay. This should be a problem with unmapping performance that I'm
>> thinking about.
>>
>> That unmapping problem is partially understood. Unmapping code works
>> correctly, but we'll need to optimize the flatview code to perform
>> unmapping immediately.
> Why immediately? Surely if we are unmapping we can defer it. Or is this
> a case of having stale mappings making the life of new allocations
> harder?

Unmapping currently works synchronously for virtio-gpu in QEMU, hence
deferring it blocks whole virtio-gpu up to 100+ ms. And if multiple
unmappings are done in a row, then it's 100ms multiplied by the number
of unmappings.

-- 
Best regards,
Dmitry

Re: [PATCH v6 00/10] Support virtio-gpu DRM native context

[Alex Bennée]

Dmitry Osipenko <dmitry.osipenko@collabora.com> writes:

> On 2/17/25 18:22, Alex Bennée wrote:
> ...
>>> This VK_KHR_display problem is only reproducible with your rootfs that
>>> you shared with me. It could be a trouble with your build configs or a
>>> buggy package version used by your rootfs build, more likely the
>>> former.
>> So you have built that latest vkmark? This is a recent addition to
>> vkmark for the 2025.1 release.
>
> Yes, latest 2025.1 from git/master.
>
>> Does vulkaninfo --summary show the extension available for you? It is
>> certainly available on the host side:
>> 
>> VK_KHR_display                         : extension revision 23
>> 
>
> Have it on guest with my rootfs, not with yours. I'd suspect problem is
> with the your Mesa build flags, maybe you haven't enabled necessary
> flags related to WSI.

I can't see any reference in the buildroot recipes. What is your mesa's
build flags?

>
> ..
>>>> With drm_native I get a lot of stutter while running and barely 100FPS
>>>> (compared to ~8000 on pure venus). IMHO we need to figure out why there
>>>> is such a discrepancy before merging because currently it makes more
>>>> sense to use 
>>> If you'd run with Xorg/Wayland directly without a DE, then it should
>>> work okay. This should be a problem with unmapping performance that I'm
>>> thinking about.
>>>
>>> That unmapping problem is partially understood. Unmapping code works
>>> correctly, but we'll need to optimize the flatview code to perform
>>> unmapping immediately.
>> Why immediately? Surely if we are unmapping we can defer it. Or is this
>> a case of having stale mappings making the life of new allocations
>> harder?
>
> Unmapping currently works synchronously for virtio-gpu in QEMU, hence
> deferring it blocks whole virtio-gpu up to 100+ ms. And if multiple
> unmappings are done in a row, then it's 100ms multiplied by the number
> of unmappings.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro