[virglrenderer-devel] multiprocess model and GL

[Chia-I Wu]

On Thu, Feb 20, 2020 at 1:25 PM Gurchetan Singh
<gurchetansingh at chromium.org> wrote:
>
> On Mon, Feb 17, 2020 at 3:12 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
> >
> >   Hi,
> >
> > > > The concern over EXECBUFFER seems to be about requiring dummy object
> > > > ids to create resources.  How about switching virgl execbuffer to use
> > > > object ids?
> > >
> > > Ah, there's the issue.  Object IDs imply something -- that subsequent
> > > rendering commands will reference them.
> >
> > No.  Object IDs can be used to reference the object, period.  Userspace
> > has the option to use that once for resource creation, then use resource
> > ids in rendering commands.  Or it can use Object IDs in rendering
> > commands.  Or a mix of both, even though that probably isn't a good
> > idea.
> >
> > > Virgl contexts won't reference the object ID.  Generic allocation
> > > contexts don't need object IDs either.  So, they are only useful in
> > > the userspace that is designed around it.  Some userspace isn't.
> >
> > Yep.  They can just use some temporary cookie for the object id.
> > Probably even some fixed value would work as there should never
> > be more than one object without an resource id assigned.
> >
> > Object IDs allow some features, specifically addressing objects the
> > kernel doesn't (need to) know anything about.  If you don't need this
> > you can create a resource for each object and after doing so just ignore
> > the object ids.  I still fail to see why this this is such a big deal
> > and why we are discussing the same thing over and over again.
> >
> > We have fundamentally three options:
> >
> >   (a) Depend on object ids.
> >   (b) Create a command set variant for allocation (doesn't need
> >       object ids because the allocation commands can get the resid
> >       from context).
> >   (c) Add ioctl to reserve resource ids (doesn't need object ids
> >       because userspace can pass the reserved resid to execbuffer
> >       allocation commands).
> >
> > (c) was discussed in the past but I think we all agreed that it isn't a
> > good idea because it introduces some non-trivial problems around
> > handling non-initialized resources and resource ownership.
> >
> > (b) is favored by Gurchetan Singh.
> >
> > (a) is favored by Gerd Hoffmann and Chia-I Wu.
> >
> > So unless someone can come up with some brilliant idea (d) we should
> > pick either (a) or (b) and move on instead of running the discussion
> > in circles a few more weeks.
>
> update: after discussing more with other members of the CrOS gfx team,
> we decided to go with (a).  I guess the next steps, in terms of kernel
> development, is perhaps landing incremental fixes in drm-misc-next ...
Yeah, internal cleanups/preparations can land in drm-misc-next.  As
for the uapi/protocol changes, I think we can create an MR from
kraxel/memory-v4 and do reviews on gitlab?

>
> >
> > My personal favorite is (a) obviously.  I think the design is better
> > and I expect this will be easier to maintain long-term.  Variant (b)
> > introduces some oddities and special cases and I suspect this might
> > get into the way some day in the future.  I don't have any hard
> > arguments, this is just a gut feeling based on a few decades
> > experience ...
> >
> > cheers,
> >   Gerd
> >