[virglrenderer-devel] multiprocess model and GL

[Gerd Hoffmann]

  Hi,

> >   (1) metadata query host to figure what stride and size will be (or
> >       maybe get that info from a cache).
> >   (2) get resource id
> Kernel needs to manage this resid space using drm_mm or something more
> suitable.  Gurchetan pointed out to me that it might be simpler for
> the userspace to manage a "local resource cookie" space.

Ok, object_id discussion again ;)

If we expose object ids at ioctl/virtio interface level (instead of
them being a thing private to mesa driver and host renderer), then we
don't need the separate "allocate resource id" step.  Userspace creates
objects via execbuffer.  Then it can create a virtio resource for that
object.  Done.

Easy for vulkan as it has a object id space anyway.

opengl uses resource ids directly, so we tried to avoid exposing object
id concept.  But, yes, I think opengl using a temporary cookie for the
object id would work.

> The flow will be
> 
>  (a) userspace generates a local object id and a local resource cookie

See above, I think you don't need both.

> >   (3) init resource (with execbuffer), which will:
> >       (a) submit the execbuffer.
> >       (b) init gem object for the resource.
> >       (c1) attach-backing for guest resources, or
> >       (c2) resource-map for host resources.
> >
> > The separate execbuffer ioctl goes away.  Batching the virtio commands
> > (notify only once) will be trivial too.
> Is supporting a NO_KICK flag for execbuffer complex or has undesirable
> implications?

Main point is to avoid a separate context switch (ioctl syscall) that
way.  There are no fundamental issues with separate EXECBUFFER and
INIT_RESOURCE ioctls.

cheers,
  Gerd