[virglrenderer-devel] multiprocess model and GL

[Chia-I Wu]

On Fri, Jan 31, 2020 at 1:06 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   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.
Wow, I did not realize that this is the very first version until you
pointed out (<img>shame_cube_meme.gif</img>).  So

v1: execbuffer w/ objid to allocate, and then resource_init w/ objid
to create resource
v2: resource_init to create resource and generate resid, and then
execbuffer w/ resid to attach
v3: generate resid first, and then execbuffer w/ resid, and then
resource_init w/ resid

v1's issue is that the kernel is given an opaque objid.  v2's issue is
that the resource does not have the host storage on creation.  v3's
issue is my concern over putting the complexity of managing a resid
space in kernel and for a usrspace to exhaust the resid space easily.

I think v1 has the simplest uapi and kernel implementation.
> > 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.
Vulkan may want to treat VkDeviceMemory and its exported fd as
different "local objects".  They will both use the local objid space.
But, yeah, GL does not have that.  The kernel does not even care.

(In case anyone is interested, when I proposed the very first version
with CTX_EXPORT_RESOURCE, the ioctl takes a VkDeviceMemory object
(identified by objid) in a per-context process, exports an fd to the
main process, and creates a resource record to manage the fd.  I moved
to v2 because I wanted to use execbuffer to do the export.  But now
that I realize that, by treating local fds as local objects, I can use
execbuffer to export even in the first version, it brings v1 back to
the table to me.  Of course, this is just what I picture Vulkan would
do internally.  GL does not need to have that.)



>
> > >   (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
>
> _______________________________________________
> virglrenderer-devel mailing list
> virglrenderer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel