On Wed, Mar 17, 2021 at 08:28:33AM +0000, Kasireddy, Vivek wrote: > Hi Gerd, > Sorry for the delayed response. I wanted to wait until I finished my > proof-of-concept -- > that included adding synchronization -- to ask follow up questions. > > > > > > > Does your work above not count for anything? > > > > It is quite old, and I think not up-to-date with the final revision of the > > blob resource > > specification. I wouldn't be able to update this in near future due to > > being busy with other > > projects. Feel free to grab & update & submit these patches though. > [Kasireddy, Vivek] Sure, we'll take a look at your work and use that as a > starting > point. Roughly, how much of your work can be reused?
There are some small udmabuf support patches which can probably be reused pretty much as-is. Everything else needs larger changes I suspect, but it's been a while I looked at this ... > Also, given my limited understanding of how discrete GPUs work, I was > wondering how > many copies would there need to be with blob resources/dmabufs and whether a > zero-copy > goal would be feasible or not? Good question. Right now there are two copies (gtk ui): (1) guest ram -> DisplaySurface -> gtk widget (gl=off), or (2) guest ram -> DisplaySurface -> texture (gl=on). You should be able to reduce this to one copy for gl=on ... (3) guest ram -> texture ... by taking DisplaySurface out of the picture, without any changes to the guest/host interface. Drawback is that it requires adding an opengl dependency to virtio-gpu even with virgl=off, because the virtio-gpu device will have to handle the copy to the texture then, in response to guest TRANSFER commands. When adding blob resource support: Easiest is probably supporting VIRTIO_GPU_BLOB_MEM_GUEST (largely identical to non-blob resources) with VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE (allows the host to create a shared mapping). Then you can go create a udmabuf for the resource on the host side. For the non-gl code path you can mmap() the udmabuf (which gives you a linear mapping for the scattered guest pages) and create a DisplaySurface backed by guest ram pages (removing the guest ram -> DisplaySurface copy). For the gl code path you can create a texture backed by the udmabuf and go render on the host without copying at all. Using VIRTIO_GPU_BLOB_MEM_GUEST + VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE for resources needs guest changes too, either in mesa (when using virgl) or the kernel driver's dumb buffer handling (when not using virgl). Alternatively (listed more for completeness): You can create a blob resource with VIRTGPU_BLOB_MEM_HOST3D (requires virgl, see also virgl_drm_winsys_resource_create_blob in mesa). It will be allocated by the host, then mapped into the guest using a virtual pci memory bar. Guest userspace (aka mesa driver) can mmap() these resources and has direct, zero-copy access to the host resource. Going to dma-buf export that, import into i915, then let the gpu render implies we are doing p2p dma from a physical (pci-assigned) device to the memory bar of a virtual pci device. Doing that should be possible, but frankly I would be surprised if that actually works out-of-the-box. Dunno how many dragons are lurking here. Could become an interesting challenge to make that fly. > > Beside the code duplication this is also a maintainance issue. This adds > > one more > > configuration to virtio-gpu. Right now you can build virtio-gpu with virgl > > (depends on > > opengl), or you can build without virgl (doesn't use opengl then). I don't > > think it is a good > > idea to add a third mode, without virgl support but using opengl for blob > > dma-bufs. > [Kasireddy, Vivek] We'll have to re-visit this part but for our use-case with > virtio-gpu, we > are disabling virglrenderer in Qemu and virgl DRI driver in the Guest. > However, we still > need to use Opengl/EGL to convert the dmabuf (guest fb) to texture and render > as part of > the UI/GTK updates. Well, VIRTGPU_BLOB_MEM_HOST3D blob resources are created using virgl renderer commands (VIRGL_CCMD_PIPE_RESOURCE_CREATE). So supporting that without virglrenderer is not an option. VIRTIO_GPU_BLOB_MEM_GUEST might be possible without too much effort. > > > On a different note, any particular reason why Qemu UI EGL > > > implementation is limited to Xorg and not extended to Wayland/Weston > > > for which there is GTK glarea? > > > > Well, ideally I'd love to just use glarea. Which happens on wayland. > > > > The problem with Xorg is that the gtk x11 backend uses glx not egl to > > create an opengl > > context for glarea. At least that used to be the case in the past, maybe > > that has changed > > with newer versions. qemu needs egl contexts though, otherwise dma-bufs > > don't work. So > > we are stuck with our own egl widget implementation for now. Probably we > > will be able > > to drop it at some point in the future. > [Kasireddy, Vivek] GTK X11 backend still uses GLX and it seems like that is > not going to > change anytime soon. Hmm, so the egl backend has to stay for the time being. > Having said that, I was wondering if it makes sense to add a new > purely Wayland backend besides GtkGlArea so that Qemu UI can more quickly > adopt new > features such as explicit sync. I was thinking about the new backend being > similar to this: > https://cgit.freedesktop.org/wayland/weston/tree/clients/simple-dmabuf-egl.c I'd prefer to not do that. > The reason why I am proposing this idea is because even if we manage to add > explicit > sync support to GTK and it gets merged, upgrading Qemu GTK support from 3.22 > to > 4.x may prove to be daunting. Currently, the way I am doing explicit > sync is > by adding these new APIs to GTK and calling them from Qemu: Well, we had the same code supporting gtk2+3 with #ifdefs. There are also #ifdefs to avoid using functions deprecated during 3.x lifetime. So I expect porting to gtk4 wouldn't be too bad. Also I expect qemu wouldn't be the only application needing sync support, so trying to get that integrated with upstream gtk certainly makes sense. > Lastly, on a different note, I noticed that there is a virtio-gpu Windows > driver here: > https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/viogpu > > We are going to try it out but do you know how up to date it is kept? No, not following development closely. take care, Gerd