[Mesa-dev] Merging virtio-gpu vulkan driver

[Chia-I Wu]

On Mon, Apr 5, 2021 at 11:12 AM Dave Airlie <airlied at gmail.com> wrote:
>
> On Tue, 6 Apr 2021 at 03:22, Chia-I Wu <olvaffe at 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 at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev