Dmitry Osipenko <dmitry.osipe...@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
