On 4/9/18 11:31 PM, qwofford wrote: > Thanks for linking me to the background reading, that was very > educational. I see that I can use VirtualGL Transport to call my GL > applications without a remote desktop, but this will introduce latency > between the client-side 2D X server, and the remote 3D X server. Perhaps > a startup script on the client which transparently launches a remote > desktop to the TurboVNC server is a better solution, because the 3D and > 2D X servers have access to the same shared memory for PBuffer swaps. > Did I understand the advantage of the X proxy correctly? Collaborative > visualization is not a concern for me, but the X proxy seems like a > better solution in any case.
Here's one: https://gist.github.com/dcommander/9137ce58a92952b23fe4def73bb8c678 In general, however, this is just a proof of concept that only works for Linux/Unix clients. In the long term, I would really like to integrate SSH more tightly with the TurboVNC Viewer, so as to enable automatically launching TurboVNC Server sessions and managing them. I may also opt to web-enable that functionality, using a built-in TurboVNC web portal that allows you to log in and manage sessions, but both tasks will take a significant amount of time that I don't have at the moment. As soon as TurboVNC 2.2 beta is released (soon), I'll be able to look at blue sky projects like that again. > Regarding the modifications to VirtualGL which would obviate the 3D X > server; in the background reading you mention: > > ... the application must still use indirect OpenGL rendering to send > 3D commands and data to the X proxy. It is, of course, much faster > to use indirect rendering over a local socket rather than a remote > socket, but there is still some overhead involved. > > > Is the 3DX to 2DX chatter the bottleneck, is the gigabit network the > bottleneck, or are they cumulative bottlenecks? You're conflating two issues. The modifications to obviate the 3D X server (we informally refer to that feature as "X-server-less GPU access" or a "GLX-to-EGL interposer") would mainly eliminate the need to run vglserver_config, as well as the need to run a 3D X server on the server machine and leave it sitting at the login prompt for no other purpose than GPU access. Doing that will make VirtualGL easier to install and maintain, from a sysadmin's point of view. It won't affect performance or usability. The background article is referring to a particular type of X proxy that implements hardware-accelerated OpenGL via indirect rendering (AKA "out-of-process", as opposed to VirtualGL, which is "in-process.") Historically, ThinAnywhere 3D (proprietary, closed-source) was such a solution, although I don't know of any others that exist at the moment. Basically that paragraph is explaining why I chose the approach I did with VirtualGL-- that is, preloading VirtualGL into the application so that the application can continue to use direct rendering despite running in a remote display environment. There are disadvantages to VirtualGL's approach-- namely that preloading libraries can cause certain "creatively-engineered" applications to break (<cough> Steam <cough>.) However, the only other known approach (indirect, out-of-process OpenGL rendering) would sacrifice performance or compatibility or both. Basically, indirect rendering can be bad because: 1. In a remote X environment, indirect OpenGL rendering means that all of the OpenGL commands and data have to be sent over the network. Bear in mind that VirtualGL was originally designed as a bolt-on technology for remote X11. It originated in the oil & gas industry, an industry in which some of the OpenGL applications-- particularly seismic visualization applications-- had to render many megabytes (sometimes even hundreds of megabytes) of unique geometry or texture data with each frame. Without VirtualGL, that data would have had to traverse the network every time a frame was rendered, which was not a tenable proposition. Also bear in mind that, when VirtualGL was first prototyped 15 years ago, high-speed X proxies simply didn't exist. TurboVNC was the first of its kind, but it remained in the prototype stage from its introduction in late 2004 until Sun Microsystems released it as a product in 2006. For quite a few years, Exceed and Exceed 3D were the standard methods of remote application access for Linux/Unix technical 3D applications, so the first releases of VirtualGL were designed mostly to work in conjunction with Exceed or with Linux clients. Also bear in mind that gigabit networking was less prevalent back then (VirtualGL was designed from the beginning to use high-speed JPEG, mainly so it could stream 3D images in real time over 100-megabit connections.) Also bear in mind that many technical applications back then used "immediate mode" rendering, which meant that they were transmitting all of the geometry to the GPU with every single frame (more impetus to avoid indirect rendering.) The scale of the indirect rendering problem has improved because of advances in network technology (gigabit is more common than not these days), improvements to the OpenGL API (applications can now use vertex arrays to avoid immediate mode while also getting around the limitations of display lists), etc. However, applications are also rendering larger and larger amounts of data, so the indirect rendering problem definitely still exists. 2. Even in a local X server/X proxy environment, indirect rendering overhead can become apparent when you try to render particularly large geometries (millions of polys), even if you're using display lists or vertex arrays. If you're using immediate-mode rendering, then the overhead becomes *really* apparent, and it becomes apparent with much smaller geometries. Even with VirtualGL, this can become a factor in performance if you're using VirtualGL to run VirtualBox or VMWare, because the VirtualBox Guest Additions and VMWare Tools add a layer of indirect OpenGL rendering between VirtualGL and the 3D application (necessary in order to communicate the OpenGL commands from the guest O/S to the host O/S.) Even on a local machine, it takes a finite amount of time for the OpenGL stack to transmit the commands and data through inter-process communication mechanisms. It's the difference between sharing a memory buffer and copying it. If you're rendering a million polygons, then a 100 ns difference in per-polygon overhead will add 10 ms per frame, which can amount to a significant difference in frame rate. 3. Indirect OpenGL rendering introduces compatibility problems. Some OpenGL features just don't work properly in that environment, and if there is a mismatch between the OpenGL implementation in the OpenGL "server" and the OpenGL implementation loaded by the application (the OpenGL "client"), then the application may not work properly or at all. It's frequently the case that indirect OpenGL implementations only support OpenGL 2 and not later versions of the API. Yet another reason why VirtualGL exists. As much as possible, VirtualGL tries to get out of the way of OpenGL functions and pass those through unmodified to the 3D X server. It's also worth pointing out that, while solving the performance problems of indirect rendering was once the "mother of invention" with regard to VirtualGL, increasingly the big selling feature of VirtualGL in more recent years has been the ability to share high-end GPUs among multiple simultaneous users and to provide access to remote GPU resources on demand. Santos was the poster child for this-- quite literally (they won the Red Hat Innovator of the Year award in 2011 for the solution they designed around VirtualGL and TurboVNC.) Rather than purchase new workstations for their hundreds of geoscience application users in 2010, they purchased eight beefy multi-pipe, massively-multi-core servers, installed VirtualGL and TurboVNC on them, and bought laptops for their users. They saved $2 million in upfront equipment costs, relative to doing a workstation refresh, plus $1 million in yearly maintenance costs. Their users claimed that the performance was actually better than their old workstations, and it was certainly more flexible, since they could access their geoscience applications from multiple locations. They-- and most other commercial VirtualGL/TurboVNC shops-- use an immersive remote desktop approach, whereby users run the TurboVNC Viewer on a Windows client and full-screen it with keyboard grabbing enabled when they want to do serious work with their Linux applications. When they want to check Outlook or whatnot, they take the TurboVNC Viewer out of full-screen mode so they can interact with their Windows desktop. With TurboVNC, there is an option to use Alt-Enter to switch in and out of full-screen mode, so it becomes a very intuitive thing to do. > You mentioned a few open and closed source solutions like TurboVNC, and > I noticed you did not mention NVIDIA's own remote visualization > solutions, GeForce Experience and the Moonlight client. Remote > visualization + GL capability appears to be an area where NVIDIA should > be leading, but it seems they are not...am I wrong? I do not work for > NVIDIA so speak freely, ha! I didn't mention it because, AFAIK, it doesn't exist on Linux servers. The Windows server/remote application space is a completely different animal, and a very difficult (if not impossible) one to tame with open source technologies. (Believe me, I've tried.) However, it's also difficult for nVidia to compete in VirtualGL's space for the same reasons-- licensing incompatibility between proprietary code and GPL/LGPL code. Also, the fact of the matter is-- VirtualGL was there first, it works for most applications, my labor is a lot cheaper than paying a big company for a support contract, and I'll work for anyone, so there is no vendor lock-in. The best we can do for Windows 3D applications at the moment is to run them in VirtualBox and run VirtualBox in VirtualGL and run VirtualGL in TurboVNC. That works, but there is a lot of overhead to it (although not really any more overhead than Microsoft's RemoteFX, which also seems to require a virtual machine in order to handle hardware-accelerated OpenGL.) -- 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/bb01b41e-79c9-b8e6-e4fd-7d9a17c0730d%40virtualgl.org. For more options, visit https://groups.google.com/d/optout.
