Sorry for the delayed response. This got lost in my inbox. I don't understand how what you're describing is any different from indirect rendering, which has performance and compatibility problems described here: https://virtualgl.org/About/Background. Not only doesn't VirtualGL support indirect rendering, but one of the big reasons why VirtualGL exists is to work around problems with indirect rendering. When VGL became fully baked in early 2003 (as a proprietary solution, well over a year before Landmark Graphics agreed to open source it), most Unix/Linux technical application users were using remote X/GLX with Exceed 3D, because that was effectively the only way to display 3D applications remotely with GPU acceleration to Windows clients (although few people were even using the term "GPU" yet.) Initially, TurboVNC wasn't a thing, and even when it became a thing, it took years for it to reach the level of maturity at which it could replace the VGL Transport. Thus, throughout most of VGL's early existence, it was primarily a bolt-on technology for remote X, and TurboVNC was primarily used only on high-latency/low-bandwidth networks where the VGL Transport didn't perform well.
Long and the short of it-- yes, you can do client-side OpenGL rendering using remote GLX. That doesn't require VirtualGL, but it does have deep performance and compatibility problems (generally indirect rendering doesn't support OpenGL > 2.1.) It also introduces more stringent requirements for Windows clients, since the Windows X servers out there mostly don't support OpenGL acceleration (I know Cygwin doesn't, for instance.) Apart from that, you're probably SOL. Supporting client-side OpenGL rendering without an X server would be hard for any solution to do, since it would require marshaling all of the OpenGL commands from server to client (a potential compatibility minefield) and then figuring out how to composite the OpenGL-rendered pixels on the client with the X-rendered pixels from the server (a potential conformance minefield.) Any solution that requires intercepting all of OpenGL, rather than just GLX, is a non-starter. It would extend the scope of VirtualGL so much that I would be incapable of singlehandedly maintaining the project, and if I'm barely able to afford paying my own bills through my work on The VirtualGL Project, I certainly can't afford to hire employees. On 2/26/19 10:39 PM, Iar De wrote: > I understand, that VGL is for offloading OpenGL to an X server with 3D > support, but, do you have a solution to do it the other way around, almost: > Is it possible, while serving a remote application, get OpenGL commands > instead of a rendered image on server, so OpenGL portion of the screen > gets rendered on client's GPU locally, not on the remote server? -- You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/613e8804-7249-5886-f593-3eb875006f37%40virtualgl.org. For more options, visit https://groups.google.com/d/optout.
