[virglrenderer-devel] multiprocess model and GL

[Gerd Hoffmann]

> > > What is the plan for guest GBM?
> >
> > --verbose please, not sure what exactly you want know.
> How is the guest GBM driver going to implement gbm_bo_create?  There
> can be a generic cpu context type that the guest GBM driver can use.
> It is also possible for the GBM driver to use virgl context type.

Right now it uses the virgl context type I assume?

So if we want continue that libgbm needs to learn the allocation
subset of the execbuffer commands, right?

Will opengl and vulkan contexts share the allocation commands?

If so it might make sense to have a separate allocation-only context
type, i.e.  gl contexts support opengl+alloc execbuffer commands, vk
contextx support vulkan+alloc execbuffer commands and the
allocation-only context supports alloc execbuffer commands.

> But you had concerns over opening /dev/dri/card0 twice when an app
> used both gl and gbm,

Well, when using one fd for all (gbm) allocations and the other fd for
all (gl) rendering the app would have to dma-buf share all resources,
which doesn't look ideal to me.

When allocating most stuff via gl context and only a few specific
resources with specfic requirements via gbm this should be much less of
a problem.

So, dunno.  What would be the use cases for gbm allocations?

> and also wanted to treat gbm allocations similar to
> dumb allocations?

Isn't the current plan to use execbuffer for everything but dumb
buffers?

cheers,
  Gerd