[virglrenderer-devel] multiprocess model and GL

[Chia-I Wu]

On Fri, Feb 7, 2020 at 12:14 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
> On Thu, Feb 06, 2020 at 02:13:41PM -0800, Chia-I Wu wrote:
> > I pushed minimal
> >
> >   https://gitlab.freedesktop.org/virgl/drm-misc-next/commits/olv/resource-v4
> >
> > based on kraxel/memory-v4 that demonstrates only capset and resource
> > creation.  The highlights are
> >
> > 1) add VIRTIO_GPU_F_MULTI_RENDERER as a generalization of VIRTIO_GPU_F_VIRGL
>
> 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.

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.

>
> > 2) VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB is made more extensible (to the
> > degree that it can support Gurchetan's args[] if we choose to)
>
> /me wonders what the point of virtio_gpu_resource_create_blob.virgl is.
> Why not simply continue using CREATE_3D for these use cases?  We have to
> keep that anyway for backward compatibility reasons ...

I think it can be removed.  It is more a migration/convenience thingy.
The kernel can internally switch classic resource allocations to use
CREATE_BLOB instead of CREATE_3D.  I also planned to use it in mesa
virgl because it provides a migration path and, additionally, it can
do SHARED or HOSTMEM.  But I now feel that we should send mesa virgl a
strong signal to migrate to execbuffer instead.

Two questions.  Can 2d and 3d transfers work on blob resources?  What
is the plan for guest GBM?

>
> cheers,
>   Gerd
>