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?
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?
