[virglrenderer-devel] multiprocess model and GL

[Gurchetan Singh]

On Fri, Jan 24, 2020 at 12:34 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   Hi,
>
> > * 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.
>
> If we don't allocate via execbuffer, how will we handle driver-only
> memory (i.e. memory which neither qemu nor kernel need to know about)?

Device local, non-exportable memory is usually a case for the 3D
driver.  A centralized allocator may need to deal with device local,
exportable memory.

> > * 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).
>
> Well, the INIT_BLOB call will basically make the object and some basic
> properties known to the host.  The actual allocation happens via
> execbuffer or ALLOC_SOMETHING call, so that would be the place where the
> host would create a gem object.
>
> Yes, VIRTGPU_MAP requests will fail if you try them on a resource after
> INIT but before ALLOC (or execbuffer allocation).
>
> > * 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).
>
> There is no need to transition to object ids.  Kernel and qemu don't
> know about object ids, they handle resources only.  If the virgl driver
> continues to work the way it does (allocate one resource per object) can
> simply continue to use resource ids.
>
> vulkan needs object ids so it can manage driver objects which are not
> known to kernel/qemu and thus don't have a resource id.
>
> > * 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.
>
> We can attach a different name to the thing.
>
> > I don't like the idea of more {width, height} ioctls with different
> > format namespaces.
>
> So, what do you want/need for gralloc and (mini)gbm allocations?

One step, (potentially) zero copy sized based allocation.  Would you
favor a virtio_gpu.h level protocol for this?

The host side allocator will depend on the host driver capabilities:
VK, host GBM, or memfd (wayland-shm).

Note: reserving resource IDs upfront (but not GEM handles) seems like
a workable idea and potentially useful for the 3D driver.  But I would
still like a potential "fast path" for associating the resource id
with the host resource.

> And, no, "just pass though an args blob" isn't an valid answer.

Can you be a bit more specific here?

I feel like this is a stylistic issue rather than a technical one.
Given the range of host allocator capabilities and the fact the
kernel/QEMU just needs to know the size + caching properties + memory
type (guest storage, host storage), it seemed reasonable not to expose
such details.

> Right
> now we have a plan for dumb objects (just size and nothing else), gl
> objects (execbuffer commands, virglrenderer interprets what virgl driver
> sends) and vk objects (execbuffer too, virvkrenderer interprets, most
> likely it will be basically vulkan structs).
>
> cheers,
>   Gerd
>