[virglrenderer-devel] multiprocess model and GL

[Chia-I Wu]

On Mon, Feb 3, 2020 at 2:04 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
> > > Because they're defined in different headers and used by different ioctls:
> > >
> > > execbuffer: https://github.com/freedesktop/virglrenderer/blob/master/src/virgl_protocol.h
> > > resouce create v1:
> > > https://github.com/freedesktop/virglrenderer/blob/master/src/virgl_hw.h
> > >
> > > (note the formats and binding types -- virglrenderer wouldn't work without it)
> > >
> > > So I wouldn't call the resource create v2 protocol as execbuffer.
> > I will say virgl_hw.h is a part of the virgl_protocol.h.  Together,
> > they define the virgl protocol.  If you look at the various _FORMAT
> > fields in virgl_protocol.h, they refers to the formats defined in
> > virgl_hw.h.
> >
> > I think a more fair way to put this is that some of the virgl protocol
> > details are leaked by drm_virtgpu_resource_create.
>
> Indeed.  We have some funny hard-coded values in the kernel because of
> that, when creating dumb resources via CREATE_3D, which don't make sense
> at all unless you have a look at the virgl protocol.
>
> > IMO, a reasonable
> > way to plug the leak is to make sure the virgl protocol details are
> > contained in EXECBUFFER in resource create v2.
>
> Agreeing here.
>
> I'm not fully though whenever execbuffer is the best option for gbm
> allocations.  gbm is just an allocation thing, not a full rendering
> protocol, so IMHO gbm objects are more like dumb object.  Specifically
> you'll go create them outside a context and go bind them to a gl/vk
> context later on to use them for rendering ...
Yeah.  Using the memory-v4 as an example, if we bet on execbuffer
fully, there would be no VIRTGPU_RESOURCE_FLAG_ALLOC_MASK.  The alloc
type would always be assumed to be
VIRTGPU_RESOURCE_FLAG_ALLOC_EXECBUFFER.  A generic gpu context type
would be defined, and its execbuffer wire format would define how to
make dumb and gbm allocations.

I think that gives a very pure resource model and resource API, but
for no practical benefit other than pureness.  Keeping
VIRTGPU_RESOURCE_FLAG_ALLOC_MASK and adding
VIRTGPU_RESOURCE_FLAG_ALLOC_CLASSIC (and adding
drm_virtgpu_resource_create to the union) seem like a good compromise
to me.  The guest userspace can use the classic alloc type to allocate
a "classic" host storage.  The host can choose to allocate using gbm
or other apis.

>
> cheers,
>   Gerd
>