<div> Thanks for the thoughtful response, Mr. Berrangé. I don't want to try the list's patience; I'm somewhat new to the ecosystem, so apologies if my posts are a bit naïve. Feel free to let me know if this conversation is better handled via another channel. And thanks so much for your blog; I just discovered it - so much valuable info! Please, anyone feel free to correct me if I'm wrong here but although I agree that creating a parallel implementation isn't ideal, I took a quick skim of virtio-gpu and my assessment is that virtio-gpu's focus on open-gl/vulcan and a lack of priotiry in supporting windows/directx means that avenue is probably not worth holding out much hope for. At least not in the near-term. And beyond the code issues, graphics card vendors don't seem at all interested in opening up their propritary datacenter-focused apis to consumer workstation scenarios making the situation ever more problematic. Therefore despite the negatives, passthru-gpu appears to be a reasonable viable path for the short-term for better windows + low-latency support. I agree my proposal isn't the ideal long-term solution, but an easy to install, well-integrated, highly-optimized low-latency windows solution might be quite popular and gain community support. It fills a gap while the ultimate solution is developed, and it should be a lot easier to implement than a shared-gpu approach that I doubt will ever support directx in a meaningful way. 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. Am I'm missing anything? If not it seems the path forward is check feasibility of #4 then #3, probably ending up at #2. #2 seems easiest to implement in many ways. I can just fork & sideband my own little project until it succeeds or fails. #2 also seems to be the easiest to implement for a single part-time developer, basically just folding the ideas from looking-glass into a solution that's more integrated into the existing virt-viewer / guest driver stack. The only downside is windows driver signing; obviously use developer mode to start, then either I can try to get the driver thru Microsoft's driver certification process (havent done driver development since windows 2000), or ideally RedHat would adopt & distribute the code. In general I'd rather avoid the community politics of trying to do something high-impact like propose api changes to some community's baby like spice or vnc. I attempted to contribute to the linux kernel something like 25 years ago and was publicly shamed by Linus himself and ended up leaving the open-source community and linux. I'd like to split the difference between looking-glass's "go it 100% alone" approach and the borg approach. I want to try to give back, ideally get it mainstreamed, if it gains traction great, but if it doesn't that's ok too. Your thoughts? </div>