Hi, > > When the guests virtual gfx card doesn't let the gpu render into a > > dma-buf we have to copy the bits anyway. Ideally just memcpy from guest > > framebuffer to a dma-buf (not sure drm allows that), so we can hand out > > a dma-buf handle for rendering no matter whenever the guest uses virgil > > or cirrus. > > Oh I suppose we could do that, though it could be a bit messy as the dma-buf > stuff is pretty bound up in having a gpu device to attach through, which > you won't have when using virgil. Did you mean "when not using virgil" ? For the to-be-written 'drm' frontend (the qemu side for the separate gl viewer app discussed in the other subthread) this is the way to go IMO. When using virgil the drm frontend just hands over the drm-buf to the viewer. When not using virgil allocate a drm-buf + copy DisplaySurface data to it. The viewer only has to deal with a dma-buf which it can hand over to wayland/x11 compositor for rendering, no matter what is going on inside qemu. Not sure how much sense that makes for the SDL frontend to do the same, don't know SDL interfaces good enougth. When SDL can deal with drm-buf's directly this probably is the best way, otherwise maybe not. > > Sure it's possible. All qemu UIs want a linear framebuffer they can > > operate on though. So with scatter-gather you have to copy the data > > into a linear buffer in qemu memory. Without scatter-gather you can > > pass a reference to guest memory to the UIs and avoid the extra copy. > The thing is for GL rendered UI there is no requirement for linear framebuffer > and actually SDL has no real requirement either, SDL2.0 pretty much says > you need to upload things to the final buffer anyways. DisplaySurfaces in qemu have to be linear, and I'm not sure this will ever change. The linear buffer assumption is in way to many places. So for anything you want scanout (and thus stuff into a DisplaySurface) it is very useful to be linear. You can use qemu_create_displaysurface_from() then. Otherwise it is qemu_create_displaysurface() + copy data. In virgil mode it doesn't matter I think. The gpu will render stuff into a dma-buf then, and if you mmap() the dma-buf I expect will be linear in qemu's user address space no matter how it looks like in physical memory. > But I expect we can > make virtio-vga have a feature for a linear framebuffer addition in the mmio > space if we have pci or mmio support. virtio has feature bits (with negotiation) in the spec, no need to reserve a mmio register for that. I'd suggest to use a lfb unconditionally for non-3d though. > Its my attempt to write a clean device from scratch, the current virgil > codebase is a pile of hacks to qemu just so I could get to the 3D rendering > as soon as possible, so I've started a virtio-gpu device which does > proper virtio->pci->vga layering and I'm going to try and create a multi-head > gpu that has no acceleration then add the 3D accel as a feature with an > additional vq. /me looks forward to see patches @ qemu-devel. It probably is useful to start reviewing/merging virtio-vga before the 3d stuff is finished, to sort multihead, to alert people something is coming, to get the ball rolling for the other bits needed (such as vgabios). cheers, Gerd _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel