[virglrenderer-devel] multiprocess model and GL

Chia-I Wu olvaffe at gmail.com
Thu Jan 23 23:08:13 UTC 2020


On Thu, Jan 23, 2020 at 5:29 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   Hi,
>
> > Yup, all these use cases need something like the proposed
> > VIRTIO_GPU_CMD_RESOURCE_CREATE_V2:
> >
> > https://gitlab.freedesktop.org/virgl/drm-misc-next/commit/6a940ed44df9cf8b5180d41571075c498208c81b#b3445381d2f5e962a33780262c87a47085b70f27_254_283
> >
> > Check out the userspace here:
> >
> > https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/303/diffs?commit_id=31b36c7941db74f3b2d38a9af6fa424ee1983c55
> >
> > It's pretty much like INIT_BLOB, but it's versioned by the host
> > enderer capabilities and can attach iovecs, can create guest dma-bufs
> > etc. based on flags.
> >
> > We can limit args_size to something reasonable (say 64 bytes).  We can
> > also say args_size == 0  is fine for dumb backends (though, without
> > metadata query, dumb_create should suffice?) and creates the
> > res_id->struct mapping for 3D backends.  kraxel, wdyt?
>
> I think the allocate-via-execbuffer approach is better than using flags
> and args[] in VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 ...

I think four (INIT_BLOB, ALLOC_BLOB, ALLOC_TYPED, ALLOC_IOVEC) may be
too many, but one (RESOURCE_CREATE_V2) also seems too little.  I like
the idea for INIT_BLOB to control the guest shmem and for ALLOC_* to
allocate host storage from the main process.  But I think Gurchetan
has concerns over issuing two ioctls, two vbufs, and two kicks to
allocate a resource.

Going from four to one involves two changes

 1) merging ALLOC_{BLOB,TYPED,IOVEC} into a new ALLOC_ARGS w/ args[], and then
 2) merging ALLOC_ARGS into INIT_BLOB

2) seems fine to me.  I am less sure about 1) because each of the
ALLOC_* requests the main process to allocate a different kind of
storage and requires a different set of args, but it feels like a
style issue.

Can RESOURCE_CREATE_V2 be used with EXECBUFFER to achieve the same
purpose as INIT_BLOB+EXECBUFFER?  If semantically we can have

 - RESOURCE_CREATE_V2 with flags for optional guest shmem allocation
and with args[] for optional host main process allocation
 - EXECBUFFER for host per-context process allocation/export/import

I am fine with RESOURCE_CREATE_V2 in general.

> cheers,
>   Gerd
>


More information about the virglrenderer-devel mailing list