[virglrenderer-devel] multiprocess model and GL

[Gurchetan Singh]

On Thu, Jan 23, 2020 at 5:29 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   Hi,
>
> > 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?
>
> I think the allocate-via-execbuffer approach is better than using flags
> and args[] in VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 ...

Why? There are many reasons why I prefer VIRTIO_GPU_CMD_RESOURCE_CREATE_V2:

* Allocating via execbuffer doesn't really fit with the centralized
allocator (gralloc for Android, GBM for Linux/ChromeOS) model.  Two
steps + keeping track of object IDs is simply not needed for this
case.
* Non-virtualized GEM drivers don't really have separate ioctls for
the creation of GEM handle and allocation.  In particular, if I call
VIRTGPU_MAP after calling drm_virtgpu_resource_init_blob, I'll have to
get the backing pages without calling drm_virtgpu_resource_alloc_blob
(or throw an error).
* Transitioning the Virgl Mesa driver to object IDs would be nice in
certain cases, but I suspect it'll take time if someone's inclined
(most people seem to think Zink + VK is the way go).  In addition,
there's no need for two-step allocation here either -- what you'll
want with that is a guest memory buffer not bound to any particular GL
objects.
* If INIT_BLOB adds the ALLOC_BLOB flag, you'll essentially be getting
VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 without the args parameters.
* ALLOC_GBM won't make much sense since GBM isn't available on Nvidia
drivers for example -- it's a capability only host/guest user space
should worry about.  I don't like the idea of more {width, height}
ioctls with different format namespaces.
* If we want a dumb ioctl that just takes a size, I think something
like drm_mode_create_dumb2 is warranted (which virtgpu will translate
to VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB).  Due to rendernode/DRM master
issues, it's good to keep dumb and 3D ioctls separate.

>
> cheers,
>   Gerd
>