[Mesa-dev] Merging virtio-gpu vulkan driver
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]. 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. [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
Re: [Mesa-dev] Merging virtio-gpu vulkan driver
On Tue, 6 Apr 2021 at 03:22, Chia-I Wu 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. > 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. 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
Re: [Mesa-dev] Merging virtio-gpu vulkan driver
On Mon, Apr 5, 2021 at 11:12 AM Dave Airlie wrote: > > On Tue, 6 Apr 2021 at 03:22, Chia-I Wu 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
