[virglrenderer-devel] multiprocess model and GL

[Chia-I Wu]

On Wed, Jan 22, 2020 at 6:51 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   Hi,
>
> > So we need to handle vk and gl resources in different ways, or figure
> > something which works for both.
>
> Saw your update @ freedesktop gitlab meanwhile.
>
> So, yes, allocating an resource id first should work.  Started new
> branch, with just the blob API patch for now:
>   https://gitlab.freedesktop.org/virgl/drm-misc-next/commits/kraxel/memory-v3
>
> New DRM_IOCTL_VIRTGPU_RESOURCE_INIT_BLOB ioctl:  Basically allocates
> IDs (resource id, bo handle).  Also passes size.
Will this generate a virtio command?

A per-context process will send (resid, fd) to the main renderer
process in response to a future execbuffer.  The main renderer process
needs to know that resid is valid and the per-context process has the
permission.  Some form of VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE seems
needed.

> Actually creating the resource should happen via execbuffer (gl/vk) or
> via DRM_IOCTL_VIRTGPU_RESOURCE_ALLOC_BLOB (dumb buffer).

As noted in another mail, the use of execbuffer to allcoate, export,
and import is a contract between the guest vk driver and the host vk
per-context processes.  I think gl should adopt a similar practice,
but it is not a hard requirement.  For example, gl can keep using the
classic resource create ioctl for allocation and rely on lazy
export/import.  It can then use resid directly.  Or perhaps gl can use
execbuffer to allocate, but export/import implicitly.

I am fine if DRM_IOCTL_VIRTGPU_RESOURCE_ALLOC_BLOB becomes a flag of
DRM_IOCTL_VIRTGPU_RESOURCE_INIT_BLOB.  Resources can have many kinds
of backing storage

 - vk resources: INIT_BLOB and then execbuffer
 - gl resources: likely INIT_BLOB and then execbuffer, but also
classic resource create or other ways?
 - dumb resources: INIT_BLOB and then ALLOC_BLOB
 - gbm resources: could be a renderer detail, but could also use an
"easy" resource create ioctl?
 - iovec-only resources: INIT_BLOB w/ flag to create shmem and attach?
 - iovec+udmabuf resources: INIT_BLOB w/ yet another flag to create a
udmabuf from iovec?
 - memfd+udmabuf resources: INIT_BLOB and then ALLOC_BLOB?
   (memfd here is a host-owned heap that appear as vram rather than
system ram to the guests)

v2 family of resource ioctls and commands should take these into
consideration.  I honestly don't know which way we want to go yet.

> Right now the ioctls and structs have the bare minimum, I suspect we'll
> need some more fields added.  So the question is:  What info can get
> passed to the host via execbuffer?  I guess pretty much anything needed
> for object creation?  How should the kernel get that metadata (the ones
> it needs for mapping etc)?  Expect guest userspace pass that to the
> kernel?  Or better ask the host?
I believe everything the host driver API needs can be passed via execbuffer.

As for metadata the kernel needs for mapping, I think it is better to
ask the host.  The kernel needs (offset-in-pci-bar, memory-type) from
the host at minimum.


>
> cheers,
>   Gerd
>