[virglrenderer-devel] multiprocess model and GL

[Chia-I Wu]

On Mon, Feb 3, 2020 at 12:25 PM Dave Airlie <airlied at gmail.com> wrote:
>
> On Sat, 1 Feb 2020 at 13:04, Chia-I Wu <olvaffe at gmail.com> wrote:
> >
> > On Fri, Jan 31, 2020 at 4:11 PM Gurchetan Singh
> > <gurchetansingh at chromium.org> wrote:
> > >
> > > On Fri, Jan 31, 2020 at 1:16 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
> > > >
> > > >   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?
> > >
> > > 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.
>
> FYI:
>
> The way it is meant to be is virgl_protocol.h is the execbuffer
> contents, that userspace drivers fill out for rendering.
> virgl_hw is meant to be the lowlevel hw interface for use by the kernel.
>
> The formats were just a bit messy and should not be seen as an
> indicator of how to move forward.
I feel the existing interface works best with a centralized allocator.
The renderers (those who execute execbuffer contents) do not allocate.
The allocator and the renderers have different protocols.

It works well when there are only GL renderers.  It is possible to
change the centralized allocator to use vulkan+export.  GL renderers
will continue to work with the help of GL_EXT_memory_object_fd.  VK
renderers can be added and they can import as well.

The main thing that model misses is that VK renderers want to make
local allocations when they are not to be mapped nor shared.  If that
model did allow local allocations, would VK renderers use objid to
identify local allocations and use resid to identify resources?  That
model also encourages implicit exports/imports.  It does not want the
guest to know that the centralized allocator might export and the
renderers might import.  But when the renderers do not have enough
info to import, or when the renderers want to associate an objid with
a resid, they rely on the guest to explicitly import again.

I think Gurchetan started from that model and fixed all the issues.
As a result, the allocation parameters are in a new opaque args[]
rather than in the existing opaque cmd[].  I like cmd[] more because

 - I use execbuffer in VK renderers to make local allocations and
import/export resources already, and
 - I did not start from that model; instead I view execbuffer as the
way to pass opaque parameters



>
> Dave.