[virglrenderer-devel] multiprocess model and GL

[Gurchetan Singh]

On Mon, Feb 10, 2020 at 12:56 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   Hi,
>
> > Which additional freedom are you afraid of?  Allocation can be done
> > both via DRM_IOCTL_VIRTGPU_RESOURCE_CREATE_BLOB and
> > DRM_IOCTL_VIRTGPU_EXECBUFFER, and both the interfaces are defined by
> > the host capabilities.
>
> Both interfaces?  It's the very same interface ...
>
> Guest userspace can use either DRM_IOCTL_VIRTGPU_EXECBUFFER +
> DRM_IOCTL_VIRTGPU_RESOURCE_CREATE_BLOB (without command buffer), or
> DRM_IOCTL_VIRTGPU_RESOURCE_CREATE_BLOB with command buffer.  The former
> is just a small optimization to avoid one extra ioctl/context switch.
>
> In both cases the guest kernel will send SUBMIT_3D and CREATE_BLOB
> commands and the host will not see a difference.
>
> > > Speaking for myself, I am uncertain if RESOURCE_CREATE_BLOB+execbuffer
> > > is enough, and wonder if the kernel should give up and go with args[].
> > > That's why there is VIRTGPU_RESOURCE_FLAG_ALLOC_MASK in case
> > > execbuffer is not enough.  If you have good use cases that are
> > > impossible with execbuffer, you should bring them up.
> >
> > There've been many proposals, so it's hard to determine exactly where
> > everyone is at given moment.
> >
> > Now that we're converging on the memory-v4 model (one-ioctl, one kick,
> > opaque arguments) [I think??], the question now is how to name the
> > opaque arguments and route to virglrenderer.
> >
> > To do an host side allocation, will it be:
> >
> > (1) DRM_IOCTL_VIRTGPU_RESOURCE_CREATE_BLOB
> >          --> VIRTIO_GPU_CMD_SUBMIT_3D -->
> > virgl_renderer_submit_cmd(void *buffer, int ctx_id, int ndw) to do the
> > allocation
> >          --> VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB -->
> > virgl_renderer_resource_create_blob(resid, size, flags, object_id,
> > ...) to consume the object id and setup res_id -> struct mapping
>
> This.
>
> > I think you favor (1) because you view driver allocation/resource
> > creation as separate.  I favor (2) because object_ids can become an
> > implementation detail too and we won't have to migrate Mesa to that
> > flow.
>
> Well, why do you want hide object ids?

Because some userspace will opt to use the object id flow, while other
user space will not.

Also, with UUIDs on the horizon, it makes sense to limit the number of IDs.

>
> Yes, having object ids makes things slightly more complicated for opengl
> because the concept of object ids doesn't exist there.  So the mesa gl
> driver needs some temporary cookie as object id.

Generating a dummy object id for the sake having an object id is
something we can avoid.

>
> The vulkan driver has object ids though, and trying to hide that creates
> a bunch of limitations.  For example it forces creating object and
> resource at the same time.

You mean it forces allocation and resource creation to occur at the
same time?  No.
Essentially, there's three commands we can put in the command buffer:

(1) ALLOCATE
(2) ASSIGN_OBJ_ID (setup [obj_id] --> [struct resource] mapping)
(3) GET_OBJ_ID  (lookup [obj_id] --> [struct resource] mapping)

Right now, VIRTIO_GPU_CMD_SUBMIT_3D does (1) and (2) [ASSIGN_OBJ_ID is
implicit in the command buffer].
virgl_renderer_resource_create_blob(resid, size, flags, obj_id)
essentially does (3).

With virgl_renderer_resource_create_blob(resid, size, flags, void
*resource_create_3d, int ndw, ..):

- setup [res_id] --> [struct resource] from a prior object via (3),
- 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).

> So if you don't know yet at object creation
> time whenever you need a resource or not you have to create a resource
> just in case because you can't do it lazily.

As lfy mentioned, we actually have hostmem for Vulkan working with an
object-id flow using the virglrenderer API above.  Not an huge issue
IMO.
>
> cheers,
>   Gerd
>