Design discussion: think about Vulkan in multiple processes + OpenGL inter-op
Assumption: libvirvrenderer.so and libvirglrenderer.so are different libraries, though living under the same virglrenderer repository
OpenGL is unlikely to go away, so it may be wise to think about our interoperability strategy as Vulkan development ramps up.
Vulkan is known as an API that will crash if you don't do something right. Some have suggested isolating each guest Vulkan physical device instance (drm fd essentially) in its own host process.
Currently, virtio-gpu creates an OpenGL context every time the driver is opened. These contexts all share the same process (call this process 0). There needs to be a mechanism for userspace to "opt-in" into Vulkan, given the proper feature bits.
Once this happens, in the multi-process model, the VMM would create a new process (process 1). If another virtgpu instance is created, another OpenGL context at process 0 would be created. If that virtgpu instance opts into Vulkan, the VMM would create another process (process 2). And so and so forth. Of course, that's just an idea.
This presents many challenges in terms of synchronization and interoperability. For example, fences will have to be reworked significantly. There'll be a need for submit_cmd_v2, resource_create_v2 etc. to distinguish between the OpenGL context (in process 0) and the Vulkan ctx (in process n). This will rely heavily on Vulkan 1.1 external memory extensions, and not every VMM may support this multiple process model. Complicated stuff, given we've haven't gotten a single process design working ;-)