[virglrenderer-devel] multiprocess model and GL

[Gerd Hoffmann]

  Hi,

> Userspace should decide which allocator to use or use EXECBUFFER,
> regardless of context.  It sets the context and therefore should know
> what's accurate virtualization for the situation.

Ok, so a separate generic-cpu context for the gbm allocator wouldn't
work.

> > execbuffer interface (but, yes, effectively not much of a difference to
> > an args blob).
> 
> Perhaps a dumb question: why is the "execbuffer" protocol/"args"
> protcol distinction important?  Using SUBMIT_CMD as a transport could
> work, but I envisage the resource creation/sharing protocol as
> different from the current execbuffer protocol (i.e, different
> header):

Hmm?  Why?  What makes the resource creation fundamentally different
from other commands for the virglrenderer?

> https://github.com/freedesktop/virglrenderer/blob/master/src/virgl_protocol.h
> 
> Note: I think the VK renderer implementation doesn't modify the
> virgl_protocol.h either, but uses EXECBUFFER.

Other renderer, other execbuffer format, host can look at the context
type to figure which renderer should interpret this.

> As Chia pointed out, (2) is unnecessary when the object id is in the
> variadic arguments.

See other reply, we explicitly tried to avoid that, but yes it makes
sense to rethink that as it probably is simpler in the end.

> Batching hypercalls is easier than batching ioctls.  How easy is it to
> batch 2-3 hypercalls from one kick to a submit a single command to
> virglrenderer?  Otherwise, it'll be like:
> 
> virgl_renderer_submit_cmd (allocate and store away something)
> virgl_renderer_resource_init (get that something just to setup
> res_id->resource map)

Why do you think multiple function calls should be avoided?

cheers,
  Gerd