| Message ID | 20241015043238.114034-1-dmitry.osipenko@collabora.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Support virtio-gpu DRM native context | expand |
Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: > This patchset adds DRM native context support to VirtIO-GPU on Qemu. > It's based on the pending Venus v17 patches [1] that bring host blobs > support to virtio-gpu-gl device. > > Based-on: 20240822185110.1757429-1-dmitry.osipenko@collabora.com > > [1] > https://lore.kernel.org/qemu-devel/20240822185110.1757429-1-dmitry.osipenko@collabora.com/ Now the tree is open are you going to re-base with the tags and get it merged? We don't have long before softfreeze for 9.2!
On 10/24/24 13:09, Alex Bennée wrote: > Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: > >> This patchset adds DRM native context support to VirtIO-GPU on Qemu. >> It's based on the pending Venus v17 patches [1] that bring host blobs >> support to virtio-gpu-gl device. >> >> Based-on: 20240822185110.1757429-1-dmitry.osipenko@collabora.com >> >> [1] >> https://lore.kernel.org/qemu-devel/20240822185110.1757429-1-dmitry.osipenko@collabora.com/ > > Now the tree is open are you going to re-base with the tags and get it > merged? We don't have long before softfreeze for 9.2! The Venus patches apply cleanly to the latest base. I'll re-send them today in a hope that it will speed up the merging process. Thanks for the heads up. Patches should be waiting for Michael Tsirkin to press a button to get them merged. On the other hand, I now see MAINTAINERS says that virtio-gpu status is "Orphan", thought Michael/Gerd are in charge of it. Does it means that any QEMU maintainer with a commit access could help with applying virtio-gpu patches?
Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: > On 10/24/24 13:09, Alex Bennée wrote: >> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: >> >>> This patchset adds DRM native context support to VirtIO-GPU on Qemu. >>> It's based on the pending Venus v17 patches [1] that bring host blobs >>> support to virtio-gpu-gl device. >>> >>> Based-on: 20240822185110.1757429-1-dmitry.osipenko@collabora.com >>> >>> [1] >>> https://lore.kernel.org/qemu-devel/20240822185110.1757429-1-dmitry.osipenko@collabora.com/ >> >> Now the tree is open are you going to re-base with the tags and get it >> merged? We don't have long before softfreeze for 9.2! > > The Venus patches apply cleanly to the latest base. I'll re-send them > today in a hope that it will speed up the merging process. Thanks for > the heads up. > > Patches should be waiting for Michael Tsirkin to press a button to get > them merged. On the other hand, I now see MAINTAINERS says that > virtio-gpu status is "Orphan", thought Michael/Gerd are in charge of it. > Does it means that any QEMU maintainer with a commit access could help > with applying virtio-gpu patches? In theory although it would be better if we could find someone to step-up to maintainer duties. Could that be you?
On 10/24/24 15:45, Alex Bennée wrote: > Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: > >> On 10/24/24 13:09, Alex Bennée wrote: >>> Dmitry Osipenko <dmitry.osipenko@collabora.com> writes: >>> >>>> This patchset adds DRM native context support to VirtIO-GPU on Qemu. >>>> It's based on the pending Venus v17 patches [1] that bring host blobs >>>> support to virtio-gpu-gl device. >>>> >>>> Based-on: 20240822185110.1757429-1-dmitry.osipenko@collabora.com >>>> >>>> [1] >>>> https://lore.kernel.org/qemu-devel/20240822185110.1757429-1-dmitry.osipenko@collabora.com/ >>> >>> Now the tree is open are you going to re-base with the tags and get it >>> merged? We don't have long before softfreeze for 9.2! >> >> The Venus patches apply cleanly to the latest base. I'll re-send them >> today in a hope that it will speed up the merging process. Thanks for >> the heads up. >> >> Patches should be waiting for Michael Tsirkin to press a button to get >> them merged. On the other hand, I now see MAINTAINERS says that >> virtio-gpu status is "Orphan", thought Michael/Gerd are in charge of it. >> Does it means that any QEMU maintainer with a commit access could help >> with applying virtio-gpu patches? > > In theory although it would be better if we could find someone to > step-up to maintainer duties. Could that be you? Potentially, yes. I'd be happy to help. Though not earlier than next year as I'll be on a quite long vacation soon'ish, will get in touch with you.
This patchset adds DRM native context support to VirtIO-GPU on Qemu. It's based on the pending Venus v17 patches [1] that bring host blobs support to virtio-gpu-gl device. Based-on: 20240822185110.1757429-1-dmitry.osipenko@collabora.com [1] https://lore.kernel.org/qemu-devel/20240822185110.1757429-1-dmitry.osipenko@collabora.com/ Contarary to Virgl and Venus contexts which mediate high level GFX APIs, DRM native context [2] 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. [2] 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. Like Venus and Virgl context, DRM context requires applying WIP KVM patches [3] to host kernel, otherwise mapping of GPU memory blobs will likely fail. [3] https://lore.kernel.org/all/20240726235234.228822-1-seanjc@google.com/ 2. Use latest libvirglrenderer from upstream git/main for Freedreno and AMDGPU native contexts. For Intel use patches [4]. [4] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1384 3. On guest, use latest Mesa version for Freedreno. For AMDGPU use Mesa patches [5], for Intel [6]. [5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658 [6] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870 4. On guest, use latest Linux kernel v6.6+. Example Qemu cmdline that enables DRM context: qemu-system-x86_64 -device virtio-vga-gl,hostmem=4G,blob=on,drm=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: 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 (5): ui/sdl2: Restore original context after new context creation linux-headers: Update to Linux v6.12-rc1 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 | 154 ++++++++++-- hw/display/virtio-gpu.c | 15 ++ include/hw/virtio/virtio-gpu.h | 17 ++ include/standard-headers/drm/drm_fourcc.h | 43 ++++ include/standard-headers/linux/const.h | 17 ++ include/standard-headers/linux/ethtool.h | 226 ++++++++++++++++++ include/standard-headers/linux/fuse.h | 22 +- .../linux/input-event-codes.h | 2 + include/standard-headers/linux/pci_regs.h | 41 +++- .../standard-headers/linux/virtio_balloon.h | 16 +- include/standard-headers/linux/virtio_gpu.h | 1 + include/ui/sdl2.h | 7 + linux-headers/asm-arm64/mman.h | 9 + linux-headers/asm-arm64/unistd.h | 25 +- linux-headers/asm-generic/unistd.h | 6 +- linux-headers/asm-loongarch/kvm.h | 24 ++ linux-headers/asm-loongarch/unistd.h | 4 +- linux-headers/asm-riscv/kvm.h | 7 + linux-headers/asm-riscv/unistd.h | 41 +--- linux-headers/asm-x86/kvm.h | 2 + linux-headers/asm-x86/unistd_64.h | 1 + linux-headers/asm-x86/unistd_x32.h | 1 + linux-headers/linux/bits.h | 3 + linux-headers/linux/const.h | 17 ++ linux-headers/linux/iommufd.h | 143 +++++++++-- linux-headers/linux/kvm.h | 23 +- linux-headers/linux/mman.h | 1 + linux-headers/linux/psp-sev.h | 28 +++ ui/sdl2-gl.c | 66 +++++ ui/sdl2.c | 31 +++ 32 files changed, 902 insertions(+), 107 deletions(-)