[virglrenderer-devel] multiprocess model and GL

[Gurchetan Singh]

On Wed, Jan 22, 2020 at 12:19 PM Chia-I Wu <olvaffe at gmail.com> wrote:
>
> 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)
>

Yup, all these use cases need something like the proposed
VIRTIO_GPU_CMD_RESOURCE_CREATE_V2:

https://gitlab.freedesktop.org/virgl/drm-misc-next/commit/6a940ed44df9cf8b5180d41571075c498208c81b#b3445381d2f5e962a33780262c87a47085b70f27_254_283

Check out the userspace here:

https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/303/diffs?commit_id=31b36c7941db74f3b2d38a9af6fa424ee1983c55

It's pretty much like INIT_BLOB, but it's versioned by the host
enderer capabilities and can attach iovecs, can create guest dma-bufs
etc. based on flags.

We can limit args_size to something reasonable (say 64 bytes).  We can
also say args_size == 0  is fine for dumb backends (though, without
metadata query, dumb_create should suffice?) and creates the
res_id->struct mapping for 3D backends.  kraxel, wdyt?

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