[virglrenderer-devel] multiprocess model and GL

[Gurchetan Singh]

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 ...

>
> 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
>