This is a very welcome update. I wonder: is Vulkan itself practical as a virtualized interface? I can imagine that shaders running on behalf of different VMs would need to be guarded against seeing memory meant for other VMs. Might this mean swapping in a different memory map when running on behalf of each VM, one at a time? Overhead from swapping memory maps might be better than no access at all. The use case I am concerned for is exercising Vulkan as a general compute acceleration engine, as in Kompute (http://kompute.cc), running alongside ordinary graphics rendering chores, and in place of proprietary CUDA. It would be tragic for security details to make 90+% of the computational power of our machines available only for sterile graphical rendering. If Vulkan could use a virtio-gpu backend, I guess this might come out to much the same thing. But would it lack access to GPU-specific optimizations implemented in e.g. an AMD driver and made available via higher-level Vulkan APIs not visible via virtio-gpu?