Hi David On Fri, Mar 27, 2020 at 9:52 PM David Geise <dgeise@xxxxxxxxx> wrote: [..] > I'm still just skimming & sizing things but it appears the options are: > > 1. Fork viewer at some level and become a downstream source code consumer; don't worry about compatibility, etc but don't expect pull requests to be accepted. I.e. add to the open-source jungle. > > 2. Similar to #1 but minimize the jungle-effect, try to only fork only Gtk-Spice. To support this downstream environment try to minimize changes to a hook into a separate module that implements shm I/O. Limit shm usage to guest->viewer bitmap transfers. Try to avoid memcpy's, ideally point shm directly into video card's output buffer to minimize cpu/bus overhead if possible. Alternately use RLE or other low-overhead compression. Virt-viewer project's PR acceptance possible but unlikely. > > 3. I haven't looked at the spice api yet, but look for the opportunity to re-impliment spice on a shm transport that would partially or entirely replace tcp for standalone scenarios. This seems unlikely unless spice has a good transport abstraction layer. > > 4. Look for extensibility hooks in the spice api itself which could be leveraged to implement a 'sideband' shm i/o to offload the high-bandwidth traffic (screen refresh) without changing the spice itself. Just need some way to xfer a pointer & probably a few event notifications. > > Your thoughts? > As you probably realize, this is not as simple as it may look like. There are various approaches doing hw accelerated rendering, and various combinations are possible with virtio-gpu, vgpu, and passthrough, spice or not. I think there has been some discussion about combining virtio-gpu & passthrough to do better gpu display scraping somehow. But for now, it is probably easier to setup some process in the guest, like looking-glass/streaming-agent, and give that display content somehow to the host via different means (ivshmem is probably easy, but fragile/hackish). At the client end, I would highly recommend to reuse the dmabuf mechanism we have in place to share GPU buffers/display from qemu. That dmabuf mechanism is also used by the spice client, and by vgpu, so in theory you won't have to touch spice, or spice-gtk, or virt-viewer. Iow, basic screen scraping could be done by modifying guest side and qemu only. But I believe there are better plans being discussed. I think the discussion should be moved to qemu.
