[virglrenderer-devel] multiprocess model and GL

[Chia-I Wu]

On Tue, Feb 11, 2020 at 6:19 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
> > > > 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.

(I will use gallium in place of opengl, because the virgl protocol is
really about gallium protocol, not opengl protocol)

Right now, libgbm uses resource create v1 and does not use execbuffer.
If libgbm wants to move to resource_create_blob, it needs to learn to
allocate using execbuffer.

libgbm allocations want {format, usage, width, height}.  gallium
allocations want {format, usage, width, height, levels, layers}.
vulkan allocations want {heap, size}.  libgbm allocations can be
implemented using gallium allocations.  But gallium and vulkan
allocations are different enough.

I think it is simplest to support only gallium and vulkan context
types for now, but be ready to support more types.  Mesa's libgbm uses
mesa's virgl which uses the gallium context type.  Even if there was a
allocation-only context type, it would not be used by mesa libgbm.  We
can wait and see what chromeos's minigbm wants (maybe Gurchetan has
the answer already).  The benefit of an allocation-only context type
is that the host knows that it only needs a gbm_device, not
gbm_device+EGLContext.  But if the host is smart enough to create the
EGLContext lazily, there is no real benefit other than simpler code.

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

GBM is used by window systems such as xserver or wayland.  It allows
them to allocate using GBM, render/composite using GL, and present
using DRM/KMS.  Some window systems initialize GL with
EGL_KHR_platform_gbm and the DRI device is opened only once by GBM.
Other window systems use EGL_MESA_platform_surfaceless and the DRI
device is opened twice by both GBM and EGL.  It is up to the window
system to decide whether to open the DRI once or twice, and to do a
lightweight sharing or to do dma-buf sharing.

GBM can also be used by regular apps that use a multi-process
producer/consumer model.  Unless the apps are headless, they tend to
use EGL_KHR_platform_x11 (or the like) and the DRI device is opened
twice.

GBM and EGL are two different APIs that, unless one is initialized
from another such as using EGL_KHR_platform_gbm, resource sharing goes
via dma-buf export/import.

In all cases, userspace makes GBM allocations only when the
allocations are to be shared with another process.


> > and also wanted to treat gbm allocations similar to
> > dumb allocations?
>
> Isn't the current plan to use execbuffer for everything but dumb
> buffers?

Great!

> cheers,
>   Gerd
>