Well, I’m not sure this thread qualifies as a proper guide - and I would not encourage the deployment of gl-streaming in its current state. It is really still experimental, and I post those updates to let people know what’s coming, hoping others will join to make this a reality faster 
@yann I agree and see now that I made a mistake moving this out of General Discussion. Will reverse that, sorry.
It’s been some time since the last update - large impact on the code for shared-memory support, and too little time to work on this
On the way to using shared memory between a qube and its sys-gui-gpu, I just reached a nice milestone, even if it does not translate into any immediate improvement for the Real Thing: a PoC for local inter-process shared-memory has promising benchmarks: the overall glmark2 result shows the cost of the gl-streaming processing drop by half when compared to the previously-best setup (stdio transport), with a score only 20% below the native one. A couple of complex benches still show a significantly larger overhead (more than 70%), which likely show that real-life use will still need more work.
This branch is really still a mess for now, and nowhere near mainlining; I intend to see first how much those changes live up to sharing memory between VMs – and then get back to finishing all those PoC branches into something solid enough for larger publication.
2 Likes
I’ve been using Qubes for many years now (I started with 3.2, or was it 3.1?) and I have slowly been coming to the conclusion that what you are working on is something that is going to be absolutely critical in the not far future.
More and more software is starting to require a GPU for acceptable performance. Already a lot of web sites simply doesn’t work on Qubes because they use webgl. Even applications such as Libreoffice uses GPU.
My main laptop is a T490 running Qubes, but I currently have an extra workstation that does not run Qubes, and this is only because I need the GPU on it (not necessarily for games, but just to be able to use a web browser in 4k at a reasonable speed). I think for a lot of people, the alternative to using the GPU in Qubes is not “don’t use the GPU”, but rather “don’t use Qubes”, and that’s quantifiably worse than lack of security caused by sharing of the GPU.
I’m posting this because even though I personally am happy with my Qubes laptop, I also want to see more people using Qubes, but the value proposition is very hard when they are being asked to let go of GPU support. I’m hoping that this project may be the solution to this at some point.
3 Likes
Following via email. As of right now, I’m very much a gamer, and don’t have a second GPU (not even an iGPU) for passthrough shenanigans. Without this feature, there’s no way I can ever give Qubes any serious consideration.
I notice the repo has been idle for some months now. I’d ask what I could do to help, but unfortunately, I’m not a C programmer, so it’s not viable for me to jump in. But, best of luck, and I hope this project continues.
2 Likes
This project will anyway be most useful with a primary-GPU passthrough setup (sys-gui-gpu), so you can start possibly with getting that setup working (easier with Intel iGPUs, as of today).
Yann, if I understand correctly, transferring OpenGL/Vulkan calls to sys-gui-gpu will essentially mean that no graphics processing will actually happen outside of the sys-gui-gpu VM? I am following this thread and really hope to see this coming up. There’s also a project on the github repo (although using a different technology) for GPU hardware acceleration if you’re interested.
Thanks