[virglrenderer-devel] multiprocess model and GL

[Gurchetan Singh]

On Mon, Jan 27, 2020 at 1:54 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   Hi,
>
> > > And, no, "just pass though an args blob" isn't an valid answer.
> >
> > Can you be a bit more specific here?
> >
> > I feel like this is a stylistic issue rather than a technical one.
> > Given the range of host allocator capabilities and the fact the
> > kernel/QEMU just needs to know the size + caching properties + memory
> > type (guest storage, host storage), it seemed reasonable not to expose
> > such details.
>
> Those details still need to be defined, and "an args blob" clearly isn't
> that.
>
> Not including the details in the virtio specification is fine, but we
> need a *reference* to the details then.
>
> We basically do the same with the execbuffer format.  That is defined by
> mesa and virglrenderer instead of being written down as part of the
> virtio-gpu spec.
>
> In case you want keep the door open to change the format/content of the
> allocator args blob we also need some plan for backward compatibility,
> using a capset for example.

Yes, of course.  That's what the demo implementation does:

https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/303/diffs?commit_id=0a2461e33a3b9c40339a6fdc09da29d5ba358850

The source of truth of the resource creation/sharing protocol will
live inside virglrenderer, just like EXECBUFFER.  Obviously, lots of
clean-ups need to be done and it needs to be reviewed by virglrenderer
devs.

Note: Moving the header to virtgpu_drm.h/virtio_gpu.h interface could
be done, if you think that's warranted.  It'll make versioning/struct
chaining a little tougher though...

>
> cheers,
>   Gerd
>