Hi, > > 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. The coherent mapping (host-allocated resources into guest address space) is another thing which needs to be sorted out. > That's the direction we're interested in going, though it > looks like udmabuf is orthogonal to that. Yes, udmabuf is the other way around, guest allocates resources and we make them available as host dmabufs. > 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. Tomeu Vizoso (Cc'ed) was looking into using virtio-serial as wayland protocol transport between host and guest. With udmabuf we can use virtio-gpu drm objects to pass pixel buffers from guest to host, which is one important building block for that. Not sure what the current state is. cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
