[virglrenderer-devel] multiprocess model and GL

[Chia-I Wu]

On Fri, Jan 31, 2020 at 12:32 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
>   Hi,
>
> > > The problematic ones are the mesa-created virgl resources.  If the host
> > > (and possibly the host gpu hardware too) can see any resource updates
> > > before mesa explicitly calls the TRANSFER ioctl, would that break the
> > > driver?  Or would mesa set the "you can use udmabufs" flag anyway on all
> > > resources?
> > Oh, mesa would break.  It relies on the existence of shadow buffers
> > currently.  If there was a "you must use udmabuf" flag, mesa could
> > theoretically use it and allocate staging buffers itself when needed.
> > But if the flag was just a hint, it would not be enough.
> >
> > There are also GL_PERSISTENT_BIT buffer objects.  Mesa does not
> > support them now.  Mesa could use the "you can use udmabuf" flag to
> > support them.  But the bit is usually set along with
> > GL_MAP_COHERENT_BIT.  Mesa would still needs the "you must use
> > udmabuf" flag.
>
> Hmm, so far my plan is to have a "you can use dmabuf" flag only.
>
> Would a "you must use udmabuf" flag useful?  If GL_PERSISTENT_BIT is
> typically used together with GL_MAP_COHERENT_BIT I would expect mesa
> would try to use hostmem anyway ...
Yes, hostmem will be my first choice when available.  When hostmem is
not available, such as on COQOS, I might want a dedicated heap[1] than
the "you must use udmabuf" flag.  Unless someone has a use case, I am
fine leaving it out for now.

[1] https://gitlab.freedesktop.org/virgl/virglrenderer/issues/159

>
> cheers,
>   Gerd
>