[virglrenderer-devel] multiprocess model and GL

[Chia-I Wu]

On Mon, Feb 3, 2020 at 2:17 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   Hi,
>
> > > > virgl_renderer_submit_cmd (allocate and store away something)
> > > > virgl_renderer_resource_init (get that something just to setup
> > > > res_id->resource map)
> > >
> > > Why do you think multiple function calls should be avoided?
> >
> > It makes the userspace nicer.
>
> Not sure about that.  Having one function per job which you can freely
> combine as needed tends to work better than a single does-everything
> function.
>
> > For example, it's nice to have the
> > guest SG backing and the metadata when creating a udmabuf.
>
> Well, yes, doing the backing store as separate step has its problems
> indeed.  With a shadow buffer and transfer calls this isn't much of a
> problem, but with udmabufs it kind-of sucks.
>
> Not sure why the initial design had a separate ATTACH_BACKING virtio
> command.  Maybe the idea was that you don't have to attach backing
> storage to objects which you never touch with the CPU.  The linux kernel
> attaches backing storage to all resources unconditionally though, and
> the future plan for device-only objects is that we don't create
> virtio-gpu resources in the first place.  So that point is moot I think.
> Does it make sense to pass the scatter list at resource creation time
> (for SHADOW+SHARED objects)?
As long as the backing cannot be detached, I am fine sending the sg
list as a part of VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB or with
VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING.  But it is certainly
preferable to send the sg list as a part of
VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB.

ATTACH_BACKING/DETACH_BACKING can be useful when you want to transfer
only once, such as when transferring pixel data into the host texture
once.  You can detach and free the guest shmem after transferring.
But the kernel never does that, nor has enough info to do that.  The
userspace also has other mechanisms to potentially achieve that now
(VREND_RESOURCE_STORAGE_GUEST + VIRGL_CCMD_COPY_TRANSFER3D) without
relying on the kernel.





>
> cheers,
>   Gerd
>