On Wed, Sep 12, 2018 at 11:44 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > 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. Thanks for the clarification. With dumb buffers, I guess the host can use DRM_FORMAT_MOD_LINEAR when sending the udmabuf-created buffer to the display. Note there are certain cases where tiled buffers are map-able (Intel), and with some variation of virtio_gpu_resource_create_coherent, we could expose that to the guest. That's the direction we're interested in going, though it looks like udmabuf is orthogonal to that. What details on wayland protocol proxying still need to be worked out? That's one component of the ChromiumOS solution (virtio_wl) that hasn't been up-streamed yet. That method maps guest fds to host fds. > > 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
