On Wed, Sep 12, 2018 at 08:24:00PM -0700, Gurchetan Singh wrote:
> On Wed, Sep 12, 2018 at 12:03 AM Yann Droneaud <ydroneaud@xxxxxxxxxx> wrote:
> >
> > Hi,
> >
> > Le lundi 27 août 2018 à 11:34 +0200, Gerd Hoffmann a écrit :
> > > A driver to let userspace turn memfd regions into dma-bufs.
> > >
> > > Use case: Allows qemu create dmabufs for the vga framebuffer or
> > > virtio-gpu ressources. Then they can be passed around to display
> > > those guest things on the host. To spice client for classic full
> > > framebuffer display, and hopefully some day to wayland server for
> > > seamless guest window display.
>
> Something like this is definitely needed. I assume one flow will be:
>
> 1) guest compositor allocates a buffer using udmabuf
> 2) 3D driver imports the udmabuf and renders to it
> 3) qemu turns this udmabuf into a host dma-buf
> 4) host compositor displays this dma-buf
Well, no. This is *not* about 3D, it's about software rendering, for
example cairo doing its work for gtk apps. So the workflow would be
along these lines:
(1) guest app allocates dumb drm buffer from virtio-gpu, renders to it.
(2) guest app passes the buffer to wayland guest proxy (which looks
like a wayland server/compositor to the app, but it doesn't actually
composite anything).
(3) wayland guest proxy passes buffer handle to wayland host proxy.
(4) qemu can then use the buffer handle to lookup the virtio-gpu
buffer, then use udmabuf to create a host dma-buf for it.
(5) host dma-buf can be passed to host wayland server for display, so
guest app window shows up seamlessly on the host.
Details of the wayland protocol proxying are not hashed out yet.
> In that case, how does the guest know about the host's stride /
> alignment restrictions? For example, x-tiling on Intel (good for
> display) needs to have a stride that's a multiple of 512 bytes.
For 3D rendering (aka virgl) the workflow is quite different. The guest
submits the rendering commands to the host, so the actual rendering
happens on the host gpu, to a host-allocated drm buffer. Which can be
exported as dma-buf by the gpu driver just fine.
The guest passes resources needed for rendering (textures, ...) to the
host. I'm not sure how useful udmabuf is for that, exactly because of
the gpu specific formats. It's a tradeoff: On the plus side we can
avoid allocating a host resource and copying the data, by creating and
importing a dma-buf instead. On the other hand the host can convert the
data while copying it over from the guest to a host drm buffer, to a
format preferred by the host gpu (tiling, compressing, ...), so the gpu
will perform better that way.
cheers,
Gerd
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
