[virglrenderer-devel] multiprocess model and GL

[Gerd Hoffmann]

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

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

And, no, "just pass though an args blob" isn't an valid answer.  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