| Message ID | 20241110221838.2241356-1-dmitry.osipenko@collabora.com |
|---|---|
| Headers | show |
| Series | Support virtio-gpu DRM native context | expand |
On 2024/11/11 7:18, Dmitry Osipenko wrote: > This patchset adds DRM native context support to VirtIO-GPU on Qemu. > > Contarary to Virgl and Venus contexts which mediate 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 known DRM native context drivers existing in a wild: > > - Freedreno (Qualcomm SoC GPUs), completely upstreamed > - AMDGPU, mostly merged into upstreams > - Intel (i915), merge requests are opened > - Asahi (Apple SoC GPUs), WIP status > > > # How to try out DRM context: > > 1. DRM context uses host blobs and requires latest developer version > of Linux kernel [2] that has necessary KVM fixes. > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ > > 2. Use latest libvirglrenderer from upstream git/main for Freedreno > and AMDGPU native contexts. For Intel use patches [3]. > > [3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 > > 3. On guest, use latest Mesa version for Freedreno. For AMDGPU use > Mesa patches [4], for Intel [5]. > > [4] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658 > [5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870 > > 4. On guest, use latest Linux kernel v6.6+. Apply patch [6] if you're > running Xorg in guest. > > [6] https://lore.kernel.org/dri-devel/20241020224725.179937-1-dmitry.osipenko@collabora.com/ > > 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: > > 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. > > Dmitry Osipenko (4): > 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 > > Pierre-Eric Pelloux-Prayer (1): > ui/sdl2: Implement dpy dmabuf functions > > docs/system/devices/virtio-gpu.rst | 11 ++ > hw/display/virtio-gpu-gl.c | 5 + > hw/display/virtio-gpu-virgl.c | 158 ++++++++++++++++++++++++++--- > hw/display/virtio-gpu.c | 15 +++ > include/hw/virtio/virtio-gpu.h | 16 +++ > include/ui/sdl2.h | 7 ++ > meson.build | 6 +- > ui/sdl2-gl.c | 67 ++++++++++++ > ui/sdl2.c | 42 ++++++++ > 9 files changed, 309 insertions(+), 18 deletions(-) > Now this series looks good to me. Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
On Mon, Nov 11, 2024 at 01:18:32AM +0300, Dmitry Osipenko wrote: > This patchset adds DRM native context support to VirtIO-GPU on Qemu. > > Contarary to Virgl and Venus contexts which mediate 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 known DRM native context drivers existing in a wild: > > - Freedreno (Qualcomm SoC GPUs), completely upstreamed > - AMDGPU, mostly merged into upstreams > - Intel (i915), merge requests are opened > - Asahi (Apple SoC GPUs), WIP status Took a quick look, looks ok Acked-by: Michael S. Tsirkin <mst@redhat.com> Gerd, you gonnu pick this up? Dmitry, if you will post a rebase, I can apply too. > > # How to try out DRM context: > > 1. DRM context uses host blobs and requires latest developer version > of Linux kernel [2] that has necessary KVM fixes. > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ > > 2. Use latest libvirglrenderer from upstream git/main for Freedreno > and AMDGPU native contexts. For Intel use patches [3]. > > [3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 > > 3. On guest, use latest Mesa version for Freedreno. For AMDGPU use > Mesa patches [4], for Intel [5]. > > [4] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658 > [5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870 > > 4. On guest, use latest Linux kernel v6.6+. Apply patch [6] if you're > running Xorg in guest. > > [6] https://lore.kernel.org/dri-devel/20241020224725.179937-1-dmitry.osipenko@collabora.com/ > > 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: > > 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. > > Dmitry Osipenko (4): > 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 > > Pierre-Eric Pelloux-Prayer (1): > ui/sdl2: Implement dpy dmabuf functions > > docs/system/devices/virtio-gpu.rst | 11 ++ > hw/display/virtio-gpu-gl.c | 5 + > hw/display/virtio-gpu-virgl.c | 158 ++++++++++++++++++++++++++--- > hw/display/virtio-gpu.c | 15 +++ > include/hw/virtio/virtio-gpu.h | 16 +++ > include/ui/sdl2.h | 7 ++ > meson.build | 6 +- > ui/sdl2-gl.c | 67 ++++++++++++ > ui/sdl2.c | 42 ++++++++ > 9 files changed, 309 insertions(+), 18 deletions(-) > > -- > 2.47.0
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 which mediate 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 known DRM native context drivers existing in a wild: > > - Freedreno (Qualcomm SoC GPUs), completely upstreamed > - AMDGPU, mostly merged into upstreams > - Intel (i915), merge requests are opened > - Asahi (Apple SoC GPUs), WIP status > > > # How to try out DRM context: > > 1. DRM context uses host blobs and requires latest developer version > of Linux kernel [2] that has necessary KVM fixes. > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ > > 2. Use latest libvirglrenderer from upstream git/main for Freedreno > and AMDGPU native contexts. For Intel use patches [3]. > > [3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 > Can we detect if virglrenderer has support at build time? [drm] pci: virtio-gpu-pci detected at 0000:00:02.0 [drm] Host memory window: 0x8000000000 +0x100000000 [drm] features: +virgl +edid +resource_blob +host_visible [drm] features: +context_init [drm] number of scanouts: 1 [drm] number of cap sets: 2 DRM native context support was not enabled in virglrenderer qemu: virgl could not be initialized: -1 [drm:virtio_gpu_init] *ERROR* timed out waiting for cap set 0 is a poor failure mode at runtime. > 3. On guest, use latest Mesa version for Freedreno. For AMDGPU use > Mesa patches [4], for Intel [5]. > > [4] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658 > [5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870 > > 4. On guest, use latest Linux kernel v6.6+. Apply patch [6] if you're > running Xorg in guest. > > [6] https://lore.kernel.org/dri-devel/20241020224725.179937-1-dmitry.osipenko@collabora.com/ > > 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: > > 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. > > Dmitry Osipenko (4): > 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 > > Pierre-Eric Pelloux-Prayer (1): > ui/sdl2: Implement dpy dmabuf functions > > docs/system/devices/virtio-gpu.rst | 11 ++ > hw/display/virtio-gpu-gl.c | 5 + > hw/display/virtio-gpu-virgl.c | 158 ++++++++++++++++++++++++++--- > hw/display/virtio-gpu.c | 15 +++ > include/hw/virtio/virtio-gpu.h | 16 +++ > include/ui/sdl2.h | 7 ++ > meson.build | 6 +- > ui/sdl2-gl.c | 67 ++++++++++++ > ui/sdl2.c | 42 ++++++++ > 9 files changed, 309 insertions(+), 18 deletions(-)
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 which mediate 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 known DRM native context drivers existing in a wild: > > - Freedreno (Qualcomm SoC GPUs), completely upstreamed > - AMDGPU, mostly merged into upstreams > - Intel (i915), merge requests are opened > - Asahi (Apple SoC GPUs), WIP status > > > # How to try out DRM context: > > 1. DRM context uses host blobs and requires latest developer version > of Linux kernel [2] that has necessary KVM fixes. > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ > > 2. Use latest libvirglrenderer from upstream git/main for Freedreno > and AMDGPU native contexts. For Intel use patches [3]. > > [3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 > > 3. On guest, use latest Mesa version for Freedreno. For AMDGPU use > Mesa patches [4], for Intel [5]. > > [4] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658 > [5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870 > > 4. On guest, use latest Linux kernel v6.6+. Apply patch [6] if you're > running Xorg in guest. Have you seen this failure before: ➜ ./qemu-system-x86_64 \ -machine type=q35,accel=kvm,kernel-irqchip=split \ -cpu host \ -smp 4 \ -device virtio-net-pci,netdev=unet \ -netdev user,id=unet,hostfwd=tcp::2222-:22 \ -drive driver=qcow2,file=trixie-x86_64.qcow2 \ -serial mon:stdio \ -m 24G \ -object memory-backend-memfd,id=mem,size=24G,share=on \ -device virtio-vga-gl,hostmem=4G,blob=on,drm_native_context=on \ -display gtk,gl=on,show-cursor=on \ -device virtio-tablet-pci -device virtio-keyboard-pci \ -d guest_errors,unimp,trace:virtio_gpu_cmd_get_display_info vmport: unknown command 56 virtio_gpu_cmd_get_display_info context 4 failed to dispatch CREATE_VIDEO_BUFFER: 22 vrend_decode_ctx_submit_cmd: context error reported 4 "gst-plugin-scan" Illegal command buffer 327735 context 4 failed to dispatch CREATE_VIDEO_BUFFER: 22 vrend_decode_ctx_submit_cmd: context error reported 4 "gst-plugin-scan" Illegal command buffer 327735 context 4 failed to dispatch CREATE_VIDEO_BUFFER: 22 vrend_decode_ctx_submit_cmd: context error reported 4 "gst-plugin-scan" Illegal command buffer 327735 error: kvm run failed Bad address RAX=00007fb1e8fbefa0 RBX=00005649f1f4fb34 RCX=00000000fffffffc RDX=0000000000000004 RSI=0000000000000000 RDI=0000000000100000 RBP=00005649f2063710 RSP=00007ffe221807d0 R8 =0000000000000003 R9 =00007ffe22180808 R10=0000000000000302 R11=0000000000000000 R12=0000000000000001 R13=00007ffe22180800 R14=0000000000000002 R15=0000000000000001 RIP=00007fb20bfc3f7f RFL=00010202 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 ffffffff 00c00000 CS =0033 0000000000000000 ffffffff 00a0fb00 DPL=3 CS64 [-RA] SS =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA] DS =0000 0000000000000000 ffffffff 00c00000 FS =0000 00007fb203aace80 ffffffff 00c00000 GS =0000 0000000000000000 ffffffff 00c00000 LDT=0000 0000000000000000 ffffffff 00c00000 TR =0040 fffffe67eec85000 00004087 00008b00 DPL=0 TSS64-busy GDT= fffffe67eec83000 0000007f IDT= fffffe0000000000 00000fff CR0=80050033 CR2=00005646b7f7d018 CR3=000000012852a000 CR4=00750ef0 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000d01 Code=f3 0f 11 40 58 f3 0f 10 43 08 f3 0f 11 40 5c f3 0f 10 43 0c <f3> 0f 11 78 64 f3 0f 11 50 68 f3 44 0f 11 40 6c f3 0f 11 48 70 f3 0f 11 60 74 f3 0f 11 40
On 1/8/25 16:14, Michael S. Tsirkin wrote: > On Mon, Nov 11, 2024 at 01:18:32AM +0300, Dmitry Osipenko wrote: >> This patchset adds DRM native context support to VirtIO-GPU on Qemu. >> >> Contarary to Virgl and Venus contexts which mediate 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 known DRM native context drivers existing in a wild: >> >> - Freedreno (Qualcomm SoC GPUs), completely upstreamed >> - AMDGPU, mostly merged into upstreams >> - Intel (i915), merge requests are opened >> - Asahi (Apple SoC GPUs), WIP status > > Took a quick look, looks ok > > Acked-by: Michael S. Tsirkin <mst@redhat.com> > > Gerd, you gonnu pick this up? > > Dmitry, if you will post a rebase, I can apply too. Thanks! The plan was that Alex will test this patchset on his setup and then either he or you will apply it. Will post the rebased version too, there is a minor merge conflict with the latest Qemu tree now.
On 1/10/25 15:16, 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 which mediate 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 known DRM native context drivers existing in a wild: >> >> - Freedreno (Qualcomm SoC GPUs), completely upstreamed >> - AMDGPU, mostly merged into upstreams >> - Intel (i915), merge requests are opened >> - Asahi (Apple SoC GPUs), WIP status >> >> >> # How to try out DRM context: >> >> 1. DRM context uses host blobs and requires latest developer version >> of Linux kernel [2] that has necessary KVM fixes. >> >> [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ >> >> 2. Use latest libvirglrenderer from upstream git/main for Freedreno >> and AMDGPU native contexts. For Intel use patches [3]. >> >> [3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 >> > > Can we detect if virglrenderer has support at build time? > > [drm] pci: virtio-gpu-pci detected at 0000:00:02.0 > [drm] Host memory window: 0x8000000000 +0x100000000 > [drm] features: +virgl +edid +resource_blob +host_visible > [drm] features: +context_init > [drm] number of scanouts: 1 > [drm] number of cap sets: 2 > DRM native context support was not enabled in virglrenderer > qemu: virgl could not be initialized: -1 > [drm:virtio_gpu_init] *ERROR* timed out waiting for cap set 0 > > is a poor failure mode at runtime. It's not possible to check at a build time whether virglrenderer is built with DRM support, there are no flags for that. There is no build-time dependency on DRM for Qemu, hence such flags were never needed. You can rebuild virglrenderer with enabled DRM support, rebuilding Qemu isn't needed in that case. In general, it should be up to a package maintainer to enable required virglrenderer features. It's more a Qemu's design problem that it can't initialize virglrenderer earlier, before starting VM, IMO. Overall, don't see a problem to address here.
On 1/10/25 16:38, 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 which mediate 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 known DRM native context drivers existing in a wild: >> >> - Freedreno (Qualcomm SoC GPUs), completely upstreamed >> - AMDGPU, mostly merged into upstreams >> - Intel (i915), merge requests are opened >> - Asahi (Apple SoC GPUs), WIP status >> >> >> # How to try out DRM context: >> >> 1. DRM context uses host blobs and requires latest developer version >> of Linux kernel [2] that has necessary KVM fixes. >> >> [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ >> >> 2. Use latest libvirglrenderer from upstream git/main for Freedreno >> and AMDGPU native contexts. For Intel use patches [3]. >> >> [3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 >> >> 3. On guest, use latest Mesa version for Freedreno. For AMDGPU use >> Mesa patches [4], for Intel [5]. >> >> [4] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658 >> [5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870 >> >> 4. On guest, use latest Linux kernel v6.6+. Apply patch [6] if you're >> running Xorg in guest. > > Have you seen this failure before: > > ➜ ./qemu-system-x86_64 \ > -machine type=q35,accel=kvm,kernel-irqchip=split \ > -cpu host \ > -smp 4 \ > -device virtio-net-pci,netdev=unet \ > -netdev user,id=unet,hostfwd=tcp::2222-:22 \ > -drive driver=qcow2,file=trixie-x86_64.qcow2 \ > -serial mon:stdio \ > -m 24G \ > -object memory-backend-memfd,id=mem,size=24G,share=on \ > -device virtio-vga-gl,hostmem=4G,blob=on,drm_native_context=on \ > -display gtk,gl=on,show-cursor=on \ > -device virtio-tablet-pci -device virtio-keyboard-pci \ > -d guest_errors,unimp,trace:virtio_gpu_cmd_get_display_info > vmport: unknown command 56 > virtio_gpu_cmd_get_display_info > context 4 failed to dispatch CREATE_VIDEO_BUFFER: 22 > vrend_decode_ctx_submit_cmd: context error reported 4 "gst-plugin-scan" Illegal command buffer 327735 > context 4 failed to dispatch CREATE_VIDEO_BUFFER: 22 > vrend_decode_ctx_submit_cmd: context error reported 4 "gst-plugin-scan" Illegal command buffer 327735 > context 4 failed to dispatch CREATE_VIDEO_BUFFER: 22 > vrend_decode_ctx_submit_cmd: context error reported 4 "gst-plugin-scan" Illegal command buffer 327735 > error: kvm run failed Bad address > RAX=00007fb1e8fbefa0 RBX=00005649f1f4fb34 RCX=00000000fffffffc RDX=0000000000000004 > RSI=0000000000000000 RDI=0000000000100000 RBP=00005649f2063710 RSP=00007ffe221807d0 > R8 =0000000000000003 R9 =00007ffe22180808 R10=0000000000000302 R11=0000000000000000 > R12=0000000000000001 R13=00007ffe22180800 R14=0000000000000002 R15=0000000000000001 > RIP=00007fb20bfc3f7f RFL=00010202 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0 > ES =0000 0000000000000000 ffffffff 00c00000 > CS =0033 0000000000000000 ffffffff 00a0fb00 DPL=3 CS64 [-RA] > SS =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA] > DS =0000 0000000000000000 ffffffff 00c00000 > FS =0000 00007fb203aace80 ffffffff 00c00000 > GS =0000 0000000000000000 ffffffff 00c00000 > LDT=0000 0000000000000000 ffffffff 00c00000 > TR =0040 fffffe67eec85000 00004087 00008b00 DPL=0 TSS64-busy > GDT= fffffe67eec83000 0000007f > IDT= fffffe0000000000 00000fff > CR0=80050033 CR2=00005646b7f7d018 CR3=000000012852a000 CR4=00750ef0 > DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 > DR6=00000000ffff0ff0 DR7=0000000000000400 > EFER=0000000000000d01 > Code=f3 0f 11 40 58 f3 0f 10 43 08 f3 0f 11 40 5c f3 0f 10 43 0c <f3> 0f 11 78 64 f3 0f 11 50 68 f3 44 0f 11 40 6c f3 0f 11 48 70 f3 0f 11 60 74 f3 0f 11 40 > The Qemu args look sane. Don't remember ever seeing "vmport: unknown command 56" messages. The CREATE_VIDEO_BUFFER errors are fine, VAAPI is disabled by default in virglrenderer. The "kvm run failed Bad address" will happen if you're running older pre-6.13 host kernel that don't have KVM patches. Any chance that you booted with a stock distro kernel by accident?
Alex Bennée <alex.bennee@linaro.org> writes: > 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 which mediate 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 known DRM native context drivers existing in a wild: >> >> - Freedreno (Qualcomm SoC GPUs), completely upstreamed >> - AMDGPU, mostly merged into upstreams >> - Intel (i915), merge requests are opened >> - Asahi (Apple SoC GPUs), WIP status >> >> >> # How to try out DRM context: >> >> 1. DRM context uses host blobs and requires latest developer version >> of Linux kernel [2] that has necessary KVM fixes. >> >> [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ >> >> 2. Use latest libvirglrenderer from upstream git/main for Freedreno >> and AMDGPU native contexts. For Intel use patches [3]. >> >> [3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 >> >> 3. On guest, use latest Mesa version for Freedreno. For AMDGPU use >> Mesa patches [4], for Intel [5]. >> >> [4] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658 >> [5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870 >> >> 4. On guest, use latest Linux kernel v6.6+. Apply patch [6] if you're >> running Xorg in guest. > > Have you seen this failure before: > > ➜ ./qemu-system-x86_64 \ > -machine type=q35,accel=kvm,kernel-irqchip=split \ > -cpu host \ > -smp 4 \ > -device virtio-net-pci,netdev=unet \ > -netdev user,id=unet,hostfwd=tcp::2222-:22 \ > -drive driver=qcow2,file=trixie-x86_64.qcow2 \ > -serial mon:stdio \ > -m 24G \ > -object memory-backend-memfd,id=mem,size=24G,share=on \ > -device virtio-vga-gl,hostmem=4G,blob=on,drm_native_context=on \ > -display gtk,gl=on,show-cursor=on \ > -device virtio-tablet-pci -device virtio-keyboard-pci \ > -d guest_errors,unimp,trace:virtio_gpu_cmd_get_display_info > vmport: unknown command 56 > virtio_gpu_cmd_get_display_info > context 4 failed to dispatch CREATE_VIDEO_BUFFER: 22 > vrend_decode_ctx_submit_cmd: context error reported 4 "gst-plugin-scan" Illegal command buffer 327735 > context 4 failed to dispatch CREATE_VIDEO_BUFFER: 22 > vrend_decode_ctx_submit_cmd: context error reported 4 "gst-plugin-scan" Illegal command buffer 327735 > context 4 failed to dispatch CREATE_VIDEO_BUFFER: 22 > vrend_decode_ctx_submit_cmd: context error reported 4 "gst-plugin-scan" Illegal command buffer 327735 > error: kvm run failed Bad address > RAX=00007fb1e8fbefa0 RBX=00005649f1f4fb34 RCX=00000000fffffffc RDX=0000000000000004 > RSI=0000000000000000 RDI=0000000000100000 RBP=00005649f2063710 RSP=00007ffe221807d0 > R8 =0000000000000003 R9 =00007ffe22180808 R10=0000000000000302 R11=0000000000000000 > R12=0000000000000001 R13=00007ffe22180800 R14=0000000000000002 R15=0000000000000001 > RIP=00007fb20bfc3f7f RFL=00010202 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0 > ES =0000 0000000000000000 ffffffff 00c00000 > CS =0033 0000000000000000 ffffffff 00a0fb00 DPL=3 CS64 [-RA] > SS =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA] > DS =0000 0000000000000000 ffffffff 00c00000 > FS =0000 00007fb203aace80 ffffffff 00c00000 > GS =0000 0000000000000000 ffffffff 00c00000 > LDT=0000 0000000000000000 ffffffff 00c00000 > TR =0040 fffffe67eec85000 00004087 00008b00 DPL=0 TSS64-busy > GDT= fffffe67eec83000 0000007f > IDT= fffffe0000000000 00000fff > CR0=80050033 CR2=00005646b7f7d018 CR3=000000012852a000 CR4=00750ef0 > DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 > DR6=00000000ffff0ff0 DR7=0000000000000400 > EFER=0000000000000d01 > Code=f3 0f 11 40 58 f3 0f 10 43 08 f3 0f 11 40 5c f3 0f 10 43 0c <f3> 0f 11 78 64 f3 0f 11 50 68 f3 44 0f 11 40 6c f3 0f 11 48 70 f3 0f 11 60 74 f3 0f 11 40 So this goes away with: Linux draig 6.13.0-rc6-ajb-00144-g8c8d54116fa2-dirty #27 SMP PREEMPT_DYNAMIC Fri Jan 10 16:57:29 GMT 2025 x86_64 GNU/Linux So I think is an artefact of the PFN page locking failing. I guess native context is more prone to issues? It is a bit odd as I have loads of memory and I think the intel graphics are unified memory but I don't know how you would check.
On 1/12/25 19:14, Alex Bennée wrote: > So this goes away with: > > Linux draig 6.13.0-rc6-ajb-00144-g8c8d54116fa2-dirty #27 SMP PREEMPT_DYNAMIC Fri Jan 10 16:57:29 GMT 2025 x86_64 GNU/Linux > > So I think is an artefact of the PFN page locking failing. I guess > native context is more prone to issues? It is a bit odd as I have loads > of memory and I think the intel graphics are unified memory but I don't > know how you would check. Native context is about same prone as Venus. For Intel GFX it doesn't matter much whether it's dGPU or iGPU. i915 driver would use huge pages for UMA which is affected by the same KVM/PFN issue. In a case of UMA, you may explicitly disable transparent huge pages to work around the problem, but this is no necessary anymore using 6.13+ kernel. Glad it was an easy fix!
Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: > On 1/12/25 19:14, Alex Bennée wrote: >> So this goes away with: >> >> Linux draig 6.13.0-rc6-ajb-00144-g8c8d54116fa2-dirty #27 SMP PREEMPT_DYNAMIC Fri Jan 10 16:57:29 GMT 2025 x86_64 GNU/Linux >> >> So I think is an artefact of the PFN page locking failing. I guess >> native context is more prone to issues? It is a bit odd as I have loads >> of memory and I think the intel graphics are unified memory but I don't >> know how you would check. > > Native context is about same prone as Venus. For Intel GFX it doesn't > matter much whether it's dGPU or iGPU. i915 driver would use huge pages > for UMA which is affected by the same KVM/PFN issue. In a case of UMA, > you may explicitly disable transparent huge pages to work around the > problem, but this is no necessary anymore using 6.13+ kernel. Glad it > was an easy fix! I still can't get vulkaninfo to see anything (Error vk::Instance:enumeratePhysicalDevices: ErrorInitializationFailed). I've got your mesa native-context-iris set up with VK_ICD_FILENAMES pointing at the virtio_icd.x86_64.json VK_LOADER_DEBUG=1 doesn't show anything
This patchset adds DRM native context support to VirtIO-GPU on Qemu. Contarary to Virgl and Venus contexts which mediate 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 known DRM native context drivers existing in a wild: - Freedreno (Qualcomm SoC GPUs), completely upstreamed - AMDGPU, mostly merged into upstreams - Intel (i915), merge requests are opened - Asahi (Apple SoC GPUs), WIP status # How to try out DRM context: 1. DRM context uses host blobs and requires latest developer version of Linux kernel [2] that has necessary KVM fixes. [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ 2. Use latest libvirglrenderer from upstream git/main for Freedreno and AMDGPU native contexts. For Intel use patches [3]. [3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 3. On guest, use latest Mesa version for Freedreno. For AMDGPU use Mesa patches [4], for Intel [5]. [4] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658 [5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870 4. On guest, use latest Linux kernel v6.6+. Apply patch [6] if you're running Xorg in guest. [6] https://lore.kernel.org/dri-devel/20241020224725.179937-1-dmitry.osipenko@collabora.com/ 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: 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. Dmitry Osipenko (4): 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 Pierre-Eric Pelloux-Prayer (1): ui/sdl2: Implement dpy dmabuf functions docs/system/devices/virtio-gpu.rst | 11 ++ hw/display/virtio-gpu-gl.c | 5 + hw/display/virtio-gpu-virgl.c | 158 ++++++++++++++++++++++++++--- hw/display/virtio-gpu.c | 15 +++ include/hw/virtio/virtio-gpu.h | 16 +++ include/ui/sdl2.h | 7 ++ meson.build | 6 +- ui/sdl2-gl.c | 67 ++++++++++++ ui/sdl2.c | 42 ++++++++ 9 files changed, 309 insertions(+), 18 deletions(-)