Nathan Myers
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?
Vulkan over virtio-gpu is possible in Mesa and virglrenderer as of about six months ago[1][2]. I don't know enough about Vulkan to comment on it as a virtualized interface in itself. [1]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5800 [2]: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/412