[virglrenderer-devel] multiprocess model and GL

Gurchetan Singh gurchetansingh at chromium.org
Wed Feb 12 04:36:17 UTC 2020


On Tue, Feb 11, 2020 at 6:59 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   Hi,
>
> > > The vulkan driver has object ids though, and trying to hide that creates
> > > a bunch of limitations.  For example it forces creating object and
> > > resource at the same time.
> >
> > You mean it forces allocation and resource creation to occur at the
> > same time?  No.
> > Essentially, there's three commands we can put in the command buffer:
> >
> > (1) ALLOCATE
> > (2) ASSIGN_OBJ_ID (setup [obj_id] --> [struct resource] mapping)
> > (3) GET_OBJ_ID  (lookup [obj_id] --> [struct resource] mapping)
> >
> > Right now, VIRTIO_GPU_CMD_SUBMIT_3D does (1) and (2) [ASSIGN_OBJ_ID is
> > implicit in the command buffer].
>
> (1) and (2) are not separate steps.  You need some way to address your
> object, and obj_id provides exactly that.

It depends on your protocol.  We can have
VIRGL_CMD(ALLOCATE_WITH_OBJ_ID, size) and VIRGL_CMD(ALLOCATE, size).
The difference in size of those two commands will be 1 dword.

>
> > virgl_renderer_resource_create_blob(resid, size, flags, obj_id)
> > essentially does (3).
>
> Yes, and establish res_id -> struct resource mapping.
>
> > With virgl_renderer_resource_create_blob(resid, size, flags, void
> > *resource_create_3d, int ndw, ..):
> >
> > - setup [res_id] --> [struct resource] from a prior object via (3),
>
> Hmm, how do you want find your resource here when it has no obj_id?

There is an object id, but it's embedded in the resource_create_3d
command buffer.  See the prototype:

virgl_renderer_resource_create_blob(resid, size, flags, void
*resource_create_3d, int ndw, int fd, ..)

For object ID flows, we'd have:

resource_create_3d[0] = VIRGL_CMD(GET_OBJ_ID, size)
resource_create_3d[1] = obj_id

That way, we won't force userspace to use object ids and they can
remain an implementation detail.  FYI, that's what the current VK
hostmem prototype does.

>
> > - allocate and setup [res_id] --> [struct resource] only via (1)
> > - allocate and setup both  [res_id] --> [struct resource], [obj_id]
> > -->  [struct resource] mapping via (1) and (2)
> >
> > All user space has to do is specify the right command buffer (which
> > should be less than 64 bytes).
>
> How does userspace figure the res_id?

For allocation based flows, it'll be very similar to what we have today:

virgl_renderer_resource_create_blob(resid, size, flags, void
*resource_create_3d, int ndw, int fd, ..)

The kernel will tell virglrenderer the resource id.  The
resource_create_3d command buffer would be something like:

resource_create_3d[0] = VIRGL_CMD(ALLOCATE, size) [or ALLOCATE_WITH_OBJ_ID]
resource_create_3d[1] = gltarget
resource_create_3d[1] = glbind
...

This flow is actually better for udmabuf compared to
virgl_renderer_submit_cmd(..) followed by
virgl_renderer_resource_create_blob(obj_id,..), since accurate
resource creation requires importing the fd into EGL/VK [need import
metadata] and not allocation.

Sending the resource_create_3d command buffer with
VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB is pretty easy, since it's so
small.

>
> cheers,
>   Gerd
>


More information about the virglrenderer-devel mailing list