[virglrenderer-devel] multiprocess model and GL

[Gurchetan Singh]

On Mon, Feb 10, 2020 at 12:02 PM Chia-I Wu <olvaffe at gmail.com> wrote:
>
> 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?

I have a capabilities based protocol in mind.  I want one capset to
define the allocation protocol, and execbuffer.  It makes sense to
consider that the "unified protocol" for a context type.

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

I think we should enable object ids on a case by case basis for GL.
As far as I can tell, it's potentially only useful for compute and
render targets that are never accessed?  Is that the same case for VK?

>
>
> >
> > cheers,
> >   Gerd
> >