[virglrenderer-devel] multiprocess model and GL

[Chia-I Wu]

On Mon, Feb 10, 2020 at 12:16 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
> > > 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.
How is the guest GBM driver going to implement gbm_bo_create?  There
can be a generic cpu context type that the guest GBM driver can use.
It is also possible for the GBM driver to use virgl context type.  But
you had concerns over opening /dev/dri/card0 twice when an app used
both gl and gbm, and also wanted to treat gbm allocations similar to
dumb allocations?

I think it was fine (because the app does not expect eglInitialize and
gbm_create_device to share the same fd) and responded to that.  I
don't know what you think.


>
> cheers,
>   Gerd
>