Nathan Myers <ncm@cantrip.org> writes:

> 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