[virglrenderer-devel] multiprocess model and GL

[Chia-I Wu]

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

On Wed, Feb 5, 2020 at 10:35 PM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   Hi,
>
> > > > Multiple sources are perfectly valid.  The virglrenderer protocol is a
> > > > superset of all capset defined protocols.  capset 1 and capset 2
> > > > (virgl_hw.h) only apply to virgl (context type 0).
> > > >
> > > > capset 3 version 1 can apply to context type 0
> > > > capset 3 version 2 can apply to context type 1
>
> Hmm?  I don't think version is meant to be used like this ...
>
> > The questions in my mind with memory-v4 where:
> >
> > 1) VIRTGPU_RESOURCE_FLAG_ALLOC_EXECBUFFER vs.
> > VIRTGPU_RESOURCE_FLAG_ALLOC_{3D, ARGS} -- since in Virgl, execbuffer
> > is used for (pipe context) rendering commands commands and not (pipe
> > screen) allocations, I'd tend to support the latter.  Do you
> > agree/disagree?
>
> Latest memory-v4 has just EXECBUFFER (and DUMB, for virtio only, it's
> pointless at ioctl level).
>
> Didn't we agree on using execbuffer for all allocations, so the VMM just
> passes on the execbuffer and virglrenderer handles the details?
>
> > 2) SHARED_ALLOW vs SHARED_REQUIRE --  SHARED_REQUIRE is the way to go.
> > Maybe just HOSTVMM_3D since VMM creates the dma-buf?
>
> It's named just SHARED in latest v4, but yes the plan is that the host
> can't choose but must use a shared mapping.
>
> > 3) {GET_HOST_BACKING, RELEASE_HOST_BACKING} vs. {ATTACH_HOST_BACKING,
> > DETACH_HOST_BACKING} vs. {RESOURCE_MAP, RESOURCE_UNMAP} -- something
> > like the first two seem nice, since they mirror what we have for guest
> > memory and we want to do want to batch hypercalls.  Thoughts?
>
> Well, the plan is to *not* use ATTACH_BACKING for blob resources.
> What is bad with MAP / UNMAP?
>
> > 2) How to define protocols -- I think the answer here is the capabilities set.
>
> Agree.
>
> > > This will be the core resource creation command going forward. It can
> > > create resources from context-local objects.  Once virgl_protocol.h is
> > > extended to support local allocations, it can be used with
> > > virgl_protocol.h to replace the v1 resource creation command.
> >
> > As someone (the only one?) who's looked into the virglrenderer
> > implementation, I think it's easier to extend the current model rather
> > than requiring object IDs for Virgl.  It's just the way the code is
> > structured, and it's structured that way on based the Gallium model.
>
> I don't think you have to put everything upside down just to use object
> ids as temporary cookie in virglrenderer.  Just use u64 for the id, then
> you can use ...
>
>     vrend_resource->id = (context_id << 32) | object_id
>
> ... when creating the object via execbuffer.  When creating the resource
> you can lookup the object using context_id+object_id and replace the id
> with the (global) resource_id.
>
> cheers,
>   Gerd
>