[virglrenderer-devel] multiprocess model and GL

[Gerd Hoffmann]

  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.

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