[virglrenderer-devel] multiprocess model and GL

[Gerd Hoffmann]

> > Why this?  I'd prefer F_VULKAN
> >
> > https://git.kraxel.org/cgit/linux/commit/?h=drm-virtio-memory-v4&id=28f9d1cb04ffe54121202ed9d09352cf4dad27ca
> >
> > (we probably also want a VIRTIO_GPU_CAPSET_VULKAN)
> >
> > The host then can advertise VIRGL or VULKAN or both ...
> The idea is for the feature to provide a set of new commands, which is
> the same set of commands provided by F_VIRGL plus blob-related
> commands.  Then have capsets to define the capabilities for those
> commands.  This way, it can replace F_VIRGL, F_VULKAN,
> F_STORAGE_SHARED, F_STORAGE_HOSTMEM by a single F_MULTI_RENDERER and
> three capsets (one for virgl, one for vulkan, and one for itself).
> F_VIRGL is kept only for backward compatibility.

No.  capsets are fine to negotiate execbuffer command capabilities.

Anything the kernel needs to know about will not use capsets.  So
F_RESOURCE_BLOB and F_STORAGE_* are going to stay.

So the question is how we are going to negotiate vulkan.  F_VULKAN is
one option.  Another would be F_VIRGL + CAPSET_VULKAN.

> Similar to classic resource allocation validation, the kernel does not
> validate for blob resource allocation.  The userspace uses capsets to
> know, for example, if HOSTMEM is supported.  The host validates.

Doesn't work.

qemu (or other vmm) and kernel must be involved when it comes to mapping
host resources into guest address space, so this isn't something guest
driver + virglrenderer can handle alone.

> Two questions.  Can 2d and 3d transfers work on blob resources?

No, there is VIRTIO_GPU_CMD_TRANSFER_TO_HOST_BLOB instead.

> What is the plan for guest GBM?

--verbose please, not sure what exactly you want know.

cheers,
  Gerd