[virglrenderer-devel] multiprocess model and GL

[Gurchetan Singh]

On Wed, Feb 12, 2020 at 3:37 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
> > > > - allocate and setup [res_id] --> [struct resource] only via (1)
> > > > - allocate and setup both  [res_id] --> [struct resource], [obj_id]
> > > > -->  [struct resource] mapping via (1) and (2)
> > > >
> > > > All user space has to do is specify the right command buffer (which
> > > > should be less than 64 bytes).
> > >
> > > How does userspace figure the res_id?
> >
> > For allocation based flows, it'll be very similar to what we have today:
> >
> > virgl_renderer_resource_create_blob(resid, size, flags, void
> > *resource_create_3d, int ndw, int fd, ..)
> >
> > The kernel will tell virglrenderer the resource id.
>
> Which implies the resource_create_3d isn't an execbuffer but something
> else.  It is not self-contained but depends on the given context,
> specifically the resid generated by the kernel.  You can't do the same
> via SUBMIT_3D.

Typically, virgl_renderer_submit_cmd will take in
VIRGL_CMD(ALLOCATE_WITH_OBJ_ID, size) since it needs to establish the
[obj_id] --> [struct resource] mapping.

virgl_renderer_resource_create_blob(resid, *resource_create_3d, ..)
can take in both VIRGL_CMD(ALLOCATE_WITH_OBJ_ID, size) and
VIRGL_CMD(ALLOCATE, size) [OpenGL/generic allocation contexts]).
Internally, they'll go to the same allocation functions.  User-space
will typically choose one or the other.

Both VIRGL_CMD(ALLOCATE_WITH_OBJ_ID, size) and VIRGL_CMD(ALLOCATE,
size) can be defined in the same header and same protocol namespace,
if that's desired.  Does that address your concern about having two
different protocols?

>
> > This flow is actually better for udmabuf compared to
> > virgl_renderer_submit_cmd(..) followed by
> > virgl_renderer_resource_create_blob(obj_id,..), since accurate
> > resource creation requires importing the fd into EGL/VK [need import
> > metadata] and not allocation.
>
> I don't think virgl_renderer_resource_create_blob should be involved
> into import at all.

We'll need to generate the [res_id] --> [struct resource] --> fd
mapping at the very least.

virgl_renderer_resource_create_blob(resid, obj_id, fd, ..)


> IMHO the workflow should be more like this:
>
>   (1) VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE

Since resources will now be per context, doesn't
VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB imply
VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE for the creation context (if it's
successful)?  Does it make sense to only call
VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE on importing into another context?

>   (2) VIRTIO_GPU_CMD_SUBMIT_3D, sending import metadata and
>       (if needed) obj_id.

Yeah, that flow works well for importing fds across multi-process
contexts.  Creation may be a little bit different, since we typically
have all the metadata we need and virglrenderer already has facilities
for import on creation (and it's single process)
[VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE comes after the import]:

https://github.com/freedesktop/virglrenderer/blob/master/src/virglrenderer.c#L58

>
> cheers,
>   Gerd
>