[virglrenderer-devel] multiprocess model and GL

[Gerd Hoffmann]

  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?

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.

cheers,
  Gerd