It's nice to see support for vulkan in qemu actually getting somewhere, being able to run modern accelerated workloads inside a vm (without dealing with sr-iov) is pretty cool and definitely has some use cases.
Features like this are why I prefer using QEMU directly rather than an abstraction like libvirt on top of QEMU.
Graphical interfaces like virt-manager are nice at first, but I don't need an abstraction on top of multiple hypervisors to make them all look superficially the same, because they're not. Eventually the abstraction breaks down and gets in the way.
I need the ability to use the full capability of QEMU. I'll write a shell script to manage the complexity of the arguments. At least I don't have to deal with XML, validation, and struggling with enabling the options I want that are only supported by one specific emulator, which libvirt doesn't support, because it's not common to all of the backends.
This isn't SR-IOV which is a hardware feature for virtualizimg GPUs. The problem is the OEMs that gate this feature for enterprise products. Few people buy them so the state of the software ecosystem for virtual GPU is terrible.
You don't even necessarily get it with enterprise products; last time I checked, Nvidia requires additional CAL-type licenses installed on a "certified" server from the "Nvidia Partner Network", while AMD and Intel limit it to very specific GPU product lines targeted at VDI (i.e. virtualizing your employees' "desktops" in a server room a la X/Citrix terminals).
At that point just run the code inside a chroot with a full /dev and call it good enough. No common GPU driver, firmware or hardware was designed to securely run really untrusted code from multiple tenants.
WebGL / WebGPU are a somewhat safe subset. Or at least safe enough that Google will keep funding multi-million pwn2own bounties for Chrome with WebGL / WebGPU enabled.
Ignorant question—how's this different from qemu-virgl? I've been using the latter (installed from homebrew) for the last few years passing --device virtio-vga.
I have even used it in Windows to make a legacy proprietary OpenGL application work properly with recent Windows versions + a mobile (now unsupported) AMD GPU.
Then look back to 2.2.6, it supported up to 6.10. A far cry from only supporting up to 6.6 as initially implied so I'm not seeing how GP was correct in their initial assessment.
It's nice to see support for vulkan in qemu actually getting somewhere, being able to run modern accelerated workloads inside a vm (without dealing with sr-iov) is pretty cool and definitely has some use cases.
Features like this are why I prefer using QEMU directly rather than an abstraction like libvirt on top of QEMU.
Graphical interfaces like virt-manager are nice at first, but I don't need an abstraction on top of multiple hypervisors to make them all look superficially the same, because they're not. Eventually the abstraction breaks down and gets in the way.
I need the ability to use the full capability of QEMU. I'll write a shell script to manage the complexity of the arguments. At least I don't have to deal with XML, validation, and struggling with enabling the options I want that are only supported by one specific emulator, which libvirt doesn't support, because it's not common to all of the backends.
This isn't SR-IOV which is a hardware feature for virtualizimg GPUs. The problem is the OEMs that gate this feature for enterprise products. Few people buy them so the state of the software ecosystem for virtual GPU is terrible.
You don't even necessarily get it with enterprise products; last time I checked, Nvidia requires additional CAL-type licenses installed on a "certified" server from the "Nvidia Partner Network", while AMD and Intel limit it to very specific GPU product lines targeted at VDI (i.e. virtualizing your employees' "desktops" in a server room a la X/Citrix terminals).
So this seems to be about enabling a Linux VM use Vulkan on a Linux host qith Vulkan support ?
This seems to be about possibility to enable Vulkan in any guest OS for which virtio-gpu guest driver will be developed. For Windows https://github.com/virtio-win/kvm-guest-drivers-windows/pull... is being developed, hopefully it will take off
Does this mean graphics workloads using Vulkan can be isolated and share most GPUs securely?
At that point just run the code inside a chroot with a full /dev and call it good enough. No common GPU driver, firmware or hardware was designed to securely run really untrusted code from multiple tenants.
WebGL / WebGPU are a somewhat safe subset. Or at least safe enough that Google will keep funding multi-million pwn2own bounties for Chrome with WebGL / WebGPU enabled.
Ignorant question—how's this different from qemu-virgl? I've been using the latter (installed from homebrew) for the last few years passing --device virtio-vga.
Virtio-GPU Venus is similar to Virgl except it passes through Vulkan commands rather than OpenGL
Looking forward to KDE Plasma implementing Vulkan rendering and then it would run in qemu/kvm with GPU acceleration over Vulkan rather than OpenGL.
You can use Zink (https://docs.mesa3d.org/drivers/zink.html) to translate OpenGL to Vulkan.
I have even used it in Windows to make a legacy proprietary OpenGL application work properly with recent Windows versions + a mobile (now unsupported) AMD GPU.
Unfortunately my distro is at linux version 6.8. Looking forward to trying it out someday.
Unfortunately, ZFS doesn't support anything stable beyond 6.6.
What do you mean by stable? 2.2.7 supports the 6.12 kernel if I'm not mistaken
Of course, 2.2.7, what was released checks notes 1 hour ago. So I think GP was correct at the time of their post.
https://github.com/openzfs/zfs/releases/tag/zfs-2.2.7
Then look back to 2.2.6, it supported up to 6.10. A far cry from only supporting up to 6.6 as initially implied so I'm not seeing how GP was correct in their initial assessment.
https://github.com/openzfs/zfs/releases/tag/zfs-2.2.6
Switch distros?
Well 6.13 is bleeding edge, it just started it's RC cycle. I can wait until it is mainline.