On Tue, Mar 02, 2021 at 12:03:57AM -0800, Vivek Kasireddy wrote: > This is still a WIP/RFC patch that attempts to use dmabufs for display > updates with the help of Udmabuf driver instead of pixman. This patch > is posted to the ML to elicit feedback and start a discussion whether > something like this would be useful or not for mainly non-Virgl > rendered BOs and also potentially in other cases.
Yes, it surely makes sense to go into that direction. The patch as-is doesn't, it breaks the guest/host interface. That's ok-ish for a quick proof-of-concept, but clearly not merge-able. > TODO: > - Use Blob resources for getting meta-data such as modifier, format, etc. That is pretty much mandatory. Without blob resources there is no concept of resources shared between host and guest in virtio-gpu, all data is explicitly copied with transfer commands. Which implies quite a bit of work because we don't have blob resource support in qemu yet. > - Test with Virgil rendered BOs to see if this can be used in that case.. That also opens up the question how to go forward with virtio-gpu in general. The object hierarchy we have right now (skipping pci + vga variants for simplicity): TYPE_VIRTIO_GPU_BASE (abstract base) -> TYPE_VIRTIO_GPU (in-qemu implementation) -> TYPE_VHOST_USER_GPU (vhost-user implementation) When compiled with opengl + virgl TYPE_VIRTIO_GPU has a virgl=on/off property. Having a single device is not ideal for modular builds. because the hw-display-virtio-gpu.so module has a dependency on ui-opengl.so so that is needed (due to symbol references) even for the virgl=off case. Also the code is a bit of a #ifdef mess. I think we should split TYPE_VIRTIO_GPU into two devices. Remove virgl+opengl support from TYPE_VIRTIO_GPU. Add a new TYPE_VIRTIO_GPU_VIRGL, with either TYPE_VIRTIO_GPU or TYPE_VIRTIO_GPU_BASE as parent (not sure which is easier), have all opengl/virgl support code there. I think when using opengl it makes sense to also require virgl, so we can use the virglrenderer library to manage blob resources (even when the actual rendering isn't done with virgl). Also reduces the complexity and test matrix. Maybe it even makes sense to deprecate in-qemu virgl support and focus exclusively on the vhost-user implementation, so we don't have to duplicate all work for both implementations. > Considerations/Challenges: > - One of the main concerns with using dmabufs is how to synchronize access > to them and this use-case is no different. If the Guest is running Weston, > then it could use a maximum of 4 color buffers but uses only 2 by default and > flips between them if it is not sharing the FBs with other plugins while > running with the drm backend. In this case, how do we make sure that Weston > and Qemu UI are not using the same buffer at any given time? There is graphic_hw_gl_block + graphic_hw_gl_flushed for syncronization. Right now this is only wired up in spice, and it is rather simple (just stalls virgl rendering instead of providing per-buffer syncronization). > - If we have Xorg running in the Guest, then it gets even more interesting as > Xorg in some cases does frontbuffer rendering (uses DRM_IOCTL_MODE_DIRTYFB). Well, if the guest does frontbuffer rendering we can't do much about it and have to live with rendering glitches I guess. take care, Gerd
