[virglrenderer-devel] multiprocess model and GL

[Gerd Hoffmann]

  Hi,

> > > The kernel will tell virglrenderer the resource id.
> >
> > Which implies the resource_create_3d isn't an execbuffer but something
> > else.  It is not self-contained but depends on the given context,
> > specifically the resid generated by the kernel.  You can't do the same
> > via SUBMIT_3D.
> 
> Typically, virgl_renderer_submit_cmd will take in
> VIRGL_CMD(ALLOCATE_WITH_OBJ_ID, size) since it needs to establish the
> [obj_id] --> [struct resource] mapping.
> 
> virgl_renderer_resource_create_blob(resid, *resource_create_3d, ..)
> can take in both VIRGL_CMD(ALLOCATE_WITH_OBJ_ID, size) and
> VIRGL_CMD(ALLOCATE, size) [OpenGL/generic allocation contexts]).
> Internally, they'll go to the same allocation functions.  User-space
> will typically choose one or the other.
> 
> Both VIRGL_CMD(ALLOCATE_WITH_OBJ_ID, size) and VIRGL_CMD(ALLOCATE,
> size) can be defined in the same header and same protocol namespace,
> if that's desired.  Does that address your concern about having two
> different protocols?

No.  IMHO every execbuffer command should be submittable via
virgl_renderer_submit_cmd().  And ALLOCATE isn't, no matter in which
header file we define it, because processing it needs additional
information (the resid) which isn't in the execbuffer.

> > IMHO the workflow should be more like this:
> >
> >   (1) VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE
> 
> Since resources will now be per context, doesn't
> VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB imply
> VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE for the creation context (if it's
> successful)?

Yes (for EXECBUFFER allocations, DUMB resources are a different story of
course).

> Does it make sense to only call
> VIRTIO_GPU_CMD_CTX_ATTACH_RESOURCE on importing into another context?

Yes.

cheers,
  Gerd