[virglrenderer-devel] multiprocess model and GL

[Chia-I Wu]

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

> > > 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.
Yes, I like the memory-v4 model.

When you said "opaque arguments", do you have the extended virgl
execbuffer protocol (or a generic gpu execbuffer protocol) in mind in
both userspace/kernel and guest/host interfaces?  Or do you think of a
distinct allocation protocol?


> >
> > 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.
Second 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?
>
> 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.
>
> 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.  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.
Agreed.

I would like to have only one path: [allocate an object with object
id] first and then [create a resource from object id] to keep things
simple and to send a clear signal to implementations.  I want opengl
to use that path, rather than providing a second alternative path that
[allocate an object and create a resource from it].


>
> cheers,
>   Gerd
>