On Mon, Apr 5, 2021 at 11:12 AM Dave Airlie <airl...@gmail.com> wrote: > > On Tue, 6 Apr 2021 at 03:22, Chia-I Wu <olva...@gmail.com> wrote: > > > > Hi list, > > > > We are looking to merge virtio-gpu vulkan driver > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5800 > > > > On the good side, the driver is conformant with Vulkan 1.2 (vtest) and > > Vulkan 1.1 (virtio-gpu). I only tried it on a handful of games (e.g., > > Dota 2, Hades on Proton with D3D and Vulkan backends, and some > > others), but it appeared to work with reasonable framerates. I was > > told that it works with other games as well. > > > > I tried Basemark GPU a month ago on a Core i7-7820HQ. The fps numbers were > > > > quality highend: native 17.07, vtest 16.83, virtio-gpu 16.65 > > quality medium: native 98.19, vtest 91.15, virtio-gpu 92.29 > > quality simple: native 327.52, vtest 317.17, virtio-gpu 283.02 > > > > On the bad side, the driver requires > > > > VIRTIO_GPU_F_RESOURCE_BLOB (kernel 5.11 but not supported by qemu) > > VIRTIO_GPU_F_CONTEXT_INIT (to be upstreamed[1]) > > > > As a result, it can only be tested with crosvm[2] or vtest[3]. > > > > I've no major objections to merging this in an experimental state, not > having qemu support is of course an annoyance but at some point I > suppose that bridge will have to be crossed. > > My main worry with no qemu support is locking in crosvm specific > behaviours that we later can't get back out of. Agreed. I also want the driver to be available to the much wider community that qemu has. I myself use crosvm with archlinux host+guest for developments, in addition to on chromebooks. While it works, it is not as versatile/mature as qemu is.
We have qemu support as a part of VIRTIO_GPU_F_RESOURCE_BLOB upstream task, but there was no activity recently. I can check the status and get that going again. > > > We develop using anv as the host driver mostly. Simple samples work > > when the host driver is radv, but games hit a host KVM bug quickly. > > The issue has been reported and we expect it to be fixed by upstream. > > > > The protocol for Vulkan command serialization is not finalized either. > > The driver is still marked experimental and must be enabled with > > -Dvulkan-drivers=virtio-experimental. The plan is to mark the driver > > stable after the kernel ABI and the protocol ABI are finalized. > > Sounds good. > > Is the virglrenderer side merged? or is it a case of both sides > landing close to each other. I want to land both sides close to each other. Both sides have been reviewed. virglrenderer side is ready to land https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/412 I plan to merge both sides in a day or two if the feedback on this thread is positive :) > > Dave. > > > > [1] > > https://gitlab.freedesktop.org/virgl/drm-misc-next/-/commits/context-init/ > > [2] KVM-based VMM written in Rust > > https://chromium.googlesource.com/chromiumos/platform/crosvm/ > > [3] vtest is a part of virglrenderer and is what I use for most of the > > developments > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev