qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Bennée
Subject: Re: [PATCH v6 00/10] Support virtio-gpu DRM native context
Date: Mon, 27 Jan 2025 16:17:12 +0000
User-agent: mu4e 1.12.8; emacs 29.4

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]