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.

from gl-streaming.

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.

from gl-streaming.