I'm afraid not. In order to support such a configuration, VirtualGL
would have to interpose all of OpenGL, as opposed to interposing mainly
GLX calls as it does now. Interposing all of OpenGL means that we would
have to closely track the development of that API, which is more of a
burden than I could take on as the sole maintainer of the project. I'd
have to completely refactor VGL using Mesa or some other code base that
does the heavy lifting for the OpenGL API, and I'd have to figure out
some sort of transport to use for shipping the OpenGL calls to the
server (using compression, preferably.) Presumably, I'd also have to
use the existing VGL Transport to receive images back from the server.
Even then, only a limited set of OpenGL applications could ever perform
well with such a solution. Honestly, I don't see the point of such a
solution. If the application requires more GPU resources than the
client can provide, then that is exactly why it needs to be running on
the server with VirtualGL. If the application doesn't require more GPU
resources than the client can provide, then I don't understand why you'd
want to ship the 3D rendering elsewhere.