Announcement

Collapse
No announcement yet.

VirtIO-GPU Vulkan Driver Looks To Go Upstream In Mesa

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Quackdoc
    replied
    Originally posted by leipero View Post

    And if virglrenderer is anything to go by, you will be left with that dream. It's in terrible shape, there's no proper Windows support, and it have tons of bugs and rendering issues,

    zexelon
    Use QEMU, it should work, if you experience rendering issues, downgrade to the 0.7.0 version and symlink it with libvirglrenderer.so.1 (if needed, depending on the QEMU version), it should work semi-decently afterwards.
    To be fair, there was little reason to do so in the first place. Virgl renderer is cool and all, but that is about it. gl preformance wasn't really good enough to do anything worth while in the first place. if you were doing any real work, you would be using some kind of gpu passthroughm whether it be SR-IOV/vGPU, or if you didn't need that kind of preformance, you would just use qxl or vmware gpu.

    Now there is real incentive to make the program good, especially with google wanting it for commercial purposes, where as virgl was always a cool but kinda pointless thing. so there at the very least is incentive to make it better now, then what it was before.

    Microsoft has a degree of incentive too, as this will allow them to have gpu accelerated virtual machines running under a linux host, without them needing to open source the GPU-PV host junk. and with the work they are doing to get hyper-v able to run on a linux host, I personally don't see much demerit for them, but do see plenty of benefit.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by zexelon View Post
    Alas in the end I cant get virtio-gpu to work at all on my machines. All I get is a black screen in the viewer... have tried both virt-manager, and qemu-gtk. Based on a ton of digging it looks like it may be an Nvidia driver issue. The VM appears to boot just fine but no display after enabling virtio-gpu with 3D acceleration. The machine is still reachable via the network. Seen a couple of bug reports about this over the last several months, and the only commonality I can see is Nvidia hardware.
    Nvidia drivers have a lot of annoying quriks. Like until recently you are running two X11 servers on two different TTY when you would switch between them the X11 server that lost monitor connection would have its opengl/vulkan processing completely stopped when using Nvidia closed source drivers. The new drivers opengl/vulkan will processed on the off screen render just slower when using consumer level GPUs.

    Zexelon need to check if it all the same kind of Nvidia gpu as well like all geforce cards as that would be consumer. Nvidia has been restricting stuff on consumer cards for quite some time that is not linked to hardware capability.

    Leave a comment:


  • zexelon
    replied
    Originally posted by leipero View Post

    zexelon
    Use QEMU, it should work, if you experience rendering issues, downgrade to the 0.7.0 version and symlink it with libvirglrenderer.so.1 (if needed, depending on the QEMU version), it should work semi-decently afterwards.
    Unfortunately I have tried qemu also and its the exact same issue. I have qemu 5.0 installed and nothing will render using virtio-gpu with 3D enabled. Everything appears to boot properly but nothing is ever displayed, not even the bios/efi load screens... total black screen.

    This is pretty much my exact issue: https://bbs.archlinux.org/viewtopic.php?id=254271

    Unfortunately the qemu version on Pop_OS 20.10 does not appear to have been compiled with SDL support so I can not test that aspect. I can confirm that the GTK front end is black screen only.
    Last edited by zexelon; 05 April 2021, 09:24 PM.

    Leave a comment:


  • leipero
    replied
    Originally posted by Danniello View Post
    I know that it is early version of Linux VirtIO-GPU Vulkan Driver, but let me dream a little bit about Windows support

    Windows version of VirtIO-GPU Vulkan Driver + DXVK means DirectX9/10/11 support in Windows VM without GPU passthrough!
    And if virglrenderer is anything to go by, you will be left with that dream. It's in terrible shape, there's no proper Windows support, and it have tons of bugs and rendering issues,

    zexelon
    Use QEMU, it should work, if you experience rendering issues, downgrade to the 0.7.0 version and symlink it with libvirglrenderer.so.1 (if needed, depending on the QEMU version), it should work semi-decently afterwards.

    Leave a comment:


  • Quackdoc
    replied
    This makes me happy. this will hopefully transfer to really any mesa compatible guest and host. im excited to finally have a good solution for android gaming on a desktop. and maybe even help things like anbox.

    also running multiple vulkan accelerated VMs of off one gpu.

    Leave a comment:


  • mppix
    replied
    Originally posted by zexelon View Post
    Alas in the end I cant get virtio-gpu to work at all on my machines. All I get is a black screen in the viewer... have tried both virt-manager, and qemu-gtk. Based on a ton of digging it looks like it may be an Nvidia driver issue. The VM appears to boot just fine but no display after enabling virtio-gpu with 3D acceleration. The machine is still reachable via the network. Seen a couple of bug reports about this over the last several months, and the only commonality I can see is Nvidia hardware.
    In virt-manager, you need to choose 'direct' (not use a network port) for spice. The use of virt-viewer is a mess after that (at least in debian).
    It does not work well (or at all) with win guests.
    I hope they also address the virtual display overhead (looking-glass?)

    Leave a comment:


  • ekultails
    replied
    Originally posted by Xaero_Vincent View Post
    I think this is Google sponsored work to enable Linux Steam w/ Proton and DXVK+Vulkan to work on Chromebooks in their Linux virtual machine.

    It would be cool to see Google start funding Wine development like Valve.
    I can confirm this is work that is being sponsored by Google to have Steam Proton work on Chromebooks! I've been reporting on this for a while now. [1][2] There are benchmarks up that even show that this gets 86-97% the performance compared to baremetal. [3]

    1. https://ekultails.github.io/ekultail...n-passthrough/
    2. https://www.androidpolice.com/2021/0...n-chromebooks/
    3. https://twitter.com/ekultails/status...94041866252288

    Leave a comment:


  • CattaRappa
    replied
    Originally posted by zexelon View Post
    Alas in the end I cant get virtio-gpu to work at all on my machines. All I get is a black screen in the viewer... have tried both virt-manager, and qemu-gtk. Based on a ton of digging it looks like it may be an Nvidia driver issue. The VM appears to boot just fine but no display after enabling virtio-gpu with 3D acceleration. The machine is still reachable via the network. Seen a couple of bug reports about this over the last several months, and the only commonality I can see is Nvidia hardware.
    You can work around this by using the qemu-sdl viewer instead

    Leave a comment:


  • zexelon
    replied
    Alas in the end I cant get virtio-gpu to work at all on my machines. All I get is a black screen in the viewer... have tried both virt-manager, and qemu-gtk. Based on a ton of digging it looks like it may be an Nvidia driver issue. The VM appears to boot just fine but no display after enabling virtio-gpu with 3D acceleration. The machine is still reachable via the network. Seen a couple of bug reports about this over the last several months, and the only commonality I can see is Nvidia hardware.

    Leave a comment:


  • microcode
    replied
    It'd be funny if a vendor implemented virtio-gpu in hardware. :+ )

    Leave a comment:

Working...
X