[virglrenderer-devel] multiprocess model and GL

[Dave Airlie]

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.

Dave.