On Wed, Mar 25, 2020 at 06:16:47PM +0000, David Geise wrote: > Hi, > > I've been using an open-source project that's currently in beta called > Looking Glass (https://looking-glass.hostfission.com/) to achieve high- > performance VM graphics in a standalone workstation scenario where the > guest VM and viewer are both on the host. I use it to virtualize my > windows development environment. I need it to do work in the Unreal > Engine, which requires full GPU acceleration. My understanding is that > currently GPU isn't supported directly in the virt-manager/virt-viewer > environment. I know the cloud is the big thing these days but this > windows vm-on-host scenario is an increasingly common use-case and it > seems like there's a great opportunity to improve virt-viewer/virt-manager > here. I expect if Linux were to better support a high-performance windows+ > gpu on linux scenario, this should improve consumer pc uptake of linux. This isn't my area of expertise, but my understanding was/is that the virtio-gpu device and spice are intended to fill the GPU accelerated rendering scenario. IIUC this will include shared memory buffers between guest and host QEMU and host virt-viewer (well spice-gtk), to avoid memory copies in the local scenario. I think the main difference is probably the guest focus - virtio-gpu has targetted OpenGL accleration IIUC with plans for Vulkan too, which are the common technologies for Linux, where as looking glass is presuambly focusing on Windows rendering, though honestly this is mostly guesswork on my part. > With all that being said, I'd like to ask the virt-viewer developers: > > 1. Is there any interest in developing a low-latency 'standalone' transport > for virt-viewer? Is any such work contemplated or underway? Or is some > alternative (virtio-gpu comes to mind) being worked on that is an even > better alternative? Yeah, my hope/expectation was that virtio-gpu / spice-gtk are going to solve this problem. From the virt-viewer side, we really leave all the real work to the spice-gtk client widget. virt-viewer just adds the window management on top, so we don't really get involved in low level stuff that's performance critical ourselves. > 2. Is there truly an intrinsic opposition to, say, a proposed Gtk-shm > widget & corresponding driver being added to the virt viewer project? > Would it be possible / non-problematic to develop a platform-neutral > solution to optimize latency for this local vm scenario? As you know virt-viewer/virt-manager currently have VNC and SPICE support, with majority of important work taking place in context of SPICE. It is certainly possible to add further backends, but that will obviously have a cost associated with it. Assuming the development work taking place in QEMU and spice to support accelerated graphics is going to deliver a viable solution, then I'd not be too enthusiastic about adding an alternative backend that tries to solve the same problem. I think is more compelling to users to have a single solution that can deliver everything they need rather than having to decide between many choices. > I'm contemplating whether to try to fork virt-viewer and do a shm transport > integration myself or if I should contribute to the looking-glass project > instead. Would the virt-developers like to participate or take the lead > in this? Would the repository owners be open to a pull request to such a > contribution? Would RedHat sign such a driver? I expect there might be > strategic / political implications at play here. I think perhaps it might be worth taking your message to the spice mailing list for feedback, as they can probably give a better viewpoint on the real technical details for how looking-glass project compares to the work that is being done for virtio-gpu / spice than I can, and thus whether there's a need for both solutions or better to focus on one only. > For what it's worth, I've got 25 years of multi-language experience, mostly > heavy C++, mostly on windows. My C / DDK experience is rusty (like 15 years > since I've coded in raw C, even longer since unix!) but I might be able to > contribute something worthwhile. One thing that's true for all open source projects is that there is not enough developer time todo everything they want, so whether its working on looking-glass vs spice/virtio-gpu, I'm sure there's useful work that can be contributed. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
