[virglrenderer-devel] multiprocess model and GL

[Gerd Hoffmann]

> > > - 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.

> 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.  IMHO the workflow should be more like this:

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

cheers,
  Gerd