[virglrenderer-devel] multiprocess model and GL

[Frank Yang]

On Fri, Feb 7, 2020 at 9:46 AM Chia-I Wu <olvaffe at gmail.com> wrote:

> 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.
>
>
Side note: we recently got resource create v2 + hostmem working with
Android Emulator's flavor of vk/gl virtualization. Would it be
appropriate/helpful to add another F_<capset> to capture that use case?


> 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
> >
> _______________________________________________
> virglrenderer-devel mailing list
> virglrenderer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/virglrenderer-devel/attachments/20200207/ab550825/attachment.htm>