@winboat just announced Helios their vGPU support and it definitely is a game changer. It addresses quite a lot of workflows but unusable for others. So why is that? Helios is API-level paravirtualization. What it's doing is effectively shimming the draw calls as they happen on Windows. It installs its own Vulkan driver in the guest, that driver serializes the calls and sends them over a virtio channel to the Linux host, and the host replays them on the real GPU. The finished frames then come back through a display driver (the Looking Glass IDD) over shared memory. So it's pretty nifty but there are some catches with that approach. One is you will always be behind and chasing things, like what Wine does. You're translating DirectX, OpenGL and OpenCL onto the one API you actually forward, so you have to constantly maintain the translation layers as games and apps start depending on new features. You're never done with it. The second and bigger one for users is the guest doesn't see a GPU. At best it sees a generic virtual device, not a native NVIDIA or AMD GPU, so software will not try accelerating on it. It won't work with CUDA or advanced workloads, since there is no client-side AMD or NVIDIA driver at all. Software like Cinema 4D, Ansys, Davinci Resolve, Siemens NX or many others checks for a real vendor GPU before turning on acceleration, and when it doesn't find one it just falls back to the basic Windows software renderer or refuses entirely. You can in theory emulate a Nvidia card being plugged in, but it won't accelerate like one if it doesn't see the proper drivers. There will also be latency, but this only matters for some workloads. Every submission crosses the VM boundary and every frame gets captured and copied instead of properly scanned out. If you're on Photoshop for example it will be fine, but for fast games or anything sensitive to frame timing it's a tax that passthrough doesn't pay. #linux #virtualization #Photoshop #nvidia #amd #gpu