[virglrenderer-devel] multiprocess model and GL

[Chia-I Wu]

On Thu, Jan 16, 2020 at 4:58 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
> On Mon, Jan 13, 2020 at 01:03:22PM -0800, Chia-I Wu wrote:
> > Sorry I missed this email.
> >
> > On Thu, Jan 9, 2020 at 12:54 PM Dave Airlie <airlied at gmail.com> wrote:
> > >
> > > This is just an aside to the issue discussion, but I was wondering
> > > before we heavily consider a vulkan multi-process model, could
> > > we/should we prove a GL multi-process model first?
> >
> > I think there will just be the qemu process at first, with many GL
> > contexts and one VkInstance for each guest VkInstance.  Then there
> > will be a switch to run different VkInstance in different processes
> > (unlikely, but I wonder if this can be a vk layer).  I did not plan
> > for a multi-process GL model.  Do you have anything you want to prove
> > from it?
>
> Right now we have two models:
>   - Everything in qemu.
>   - Separate virgl process (see contrib/vhost-user-gpu/ in qemu),
>     but still all gl contexts in a single process.
>
> We could try to switch vhost-user-gpu to a one-process-per-context
> model.  I think it makes sense to at least think about the resource
> management implications this would have (it would make virgl work
> simliar to vulkan):
>
>  - We would need a master process.  It runs the virtqueues and manages
>    the resources.

In the distant feature where we will be Vulkan-only, we will not want
GL-specific paths.  If we are to do multi-process GL now, I think we
should follow the multi-process Vulkan model, in the sense that GL
resources should also be created in the per-context processes and are
not usable by other processes until they go through the
export/attach/import cycle.  Attach/import is unnecessary for qemu and
main processes.

>  - We would need a per-context process.
>  - VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE would make master dma-buf export a
>    resource and the per-context process import it.  Sharing resources
>    works by calling VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE multipe times for
>    different contexts, and therefore master passing the dma-buf to
>    multiple per-context processes.

I would like to see the export and import parts to be separated out
and executed by other commands, but all three commands can be sent
together by the guest kernel when it makes senses.  Especially the
import part, the guest vulkan wants to pass some metadata and specify
an object id for the imported driver object.

The fds need to be opaque fds (as opposed to dmabuf fds) if we want to
use GL_EXT_memory_object to import, and I think we do want to use
GL_EXT_memory_object.  True exports with GL are limited in
functionality and availability.  The per-context processes should
internally treat allocations as allocations from VK or GBM, export the
objects, and then import them into GL.

> With vulkan resources would be created by the per-context process
> instead, then exported and imported by the master process.  The master
> process can allow guest access then (TRANSFER virtio commands, map into
> address space, ...).  It could also pass it on to other per-context
> processes, so they can import too, for sharing.
> This also makes it pretty obvious how sharing between virgl and vulkan
> would work:  Just use VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE + dma-bufs ...



> cheers,
>   Gerd
>