Viability of alternatives like VirtualGL or Google's gfxstream?

[ghost]

Hello, I just came across the Qubes Discourse post regarding this, and I wanted to provide input on my own efforts to achieve 3D acceleration in Qubes.

I am currently running 3D accelerated applications on Qubes by using a GPU passed directly to a VM running a separate X server and using VirtualGL to bridge the Qubes X server :0 and the new accelerated X server together, applications can be rendered via existing Qubes infrastructure with input and audio working correctly compared to other solutions described on the internet, albeit because qubes can't capture VM cursors some 3D camera systems do not function correctly. An issue was raised on the Qubes' issue tracker (QubesOS/qubes-issues#4986) but there hasn't been any meaningful activity on it.

VirtualGL also has an EGL implementation, but I could not get it to work Fedora 33 and Debian 10's Mesa is too old and is missing the EGL extensions required. I tested it on a custom Ubuntu TemplateVM and it worked, so I believe it will be viable in the future to not have to run a secondary X server, and be able to contact the GPU directly via EGL.

I believe it may be possible to use Qubes' RPC functions with qrexec to transfer graphics commands to a remote qube that holds a graphics device but I am not knowledgeable enough on the workings of it.

Another issue is that VirtualGL does not support Vulkan forwarding, and the developer appears to not be interested in implementing it at the moment due to complexity. Therefore it may be worth to explore alternatives that do, such as Google's gfxstream. It supports code forwarding over network sockets if I understand correctly, which could probably be leveraged easily via qrexec.

I am ultimately useless at providing a meaningful practical implementation, I have no formal programming experience and can only provide insight on a design proposal. It is interesting to see so much activity regarding this lately and I feel like it's the last dealbreaker of Qubes for many people.

[ydirson]

As it happens, my search had not uncovered those two project when looking for prior work. Here is my understanding from the projects overviews, especially in what they differ from what I've in mind.

Their primary and common advantage is that they are already available, and apparently advanced enough to be used right now.

VirtualGL

• really tied to GLX. EGL support is only on server side, where they emulate the GLX commands not available directly with EGL. Vulkan is won't implement.
• the program runs on the "application server", renders to offscreen framebuffer and stream the image to thin client

gl-streaming OTOH uses what they call the "Old School Approach: Indirect Rendering". This surely has drawbacks, but the VirtualGL approach just won't allow to have the GPU and the app in different qubes

gfxstream aka. vulkan-cereal

• very scarce documentation (compare this with VirtualGL's detailed one that even includes historical information to place their software in context), which does not allow to understand the architecture -- it could very well have a structure similar to VirtualGL (which would make it unsuitable for the Qubes model)
• generator for APIs, instead of handcrafted ones. I have a plan to automate code generation further in gl-streaming with preprocessor macros, for the hand-selected cases where it makes no sense to just cut'n'paste the template. But it seems that at least on GLES side they don't really deal with those cases that don't fit in the auto-generated framework (a function like glVertexAttribPointer, arguably a bad^Hhistory-laden API, appears with flag unsupported in their API definitions and does not appear to come with a custom implementation)
• huge code base, even including a copy of the Vulkan API/registry files in a directory where they mix in their own stuff (bad practice to say the least)
• low quality build instructions ("make -j24" for everyone ? really ? not even talking about their build-host.sh script referring to a non-shipped toolchain file, and their "Make sure you are using Clang as your CC and clang++ as yourCXX" instead of providing a proper build commandline)
• low quality build files (has requirements on toolchain/version but does not give a clue, does not check for library dependencies in cmakefile...)
• clang-7 from debian-10 and clang-11 from debian-11 are apparently not sufficient, the latter is still not able to build fake-android-guest (whatever that has to do with building on Linux -- looks like the main program using this, ie. their scuttlefish android emulator, leaks a bit into gfxstream)

All in all, would requires some dedication to be able to test anything, as well as to dig into the amount of code to understand if it fits at all.

[ghost]

I see, my intention would have been to use either of these as a scaffolding infrastructure paired with special Qubes' tools. I will also agree that Google's documentation is sparse and messy, and navigating their repositories feels quite challenging. Thanks for taking the time to write out this explanation.