On 3/5/15 5:55 AM, Patric Schmitz wrote: > I am trying VirtualGL for remote rendering on our visualization > cluster and have it running by now. I am streaming to a GNU/Linux > workstation using the VGL transports as of yet. The remote has a > NVIDIA GeForce GTX 780 GPU. > > I measured the following framerates with glxgears: > > Locally, on my client machine: ~4500 fps > > Remote, without any forwarding or transport: ~27500
Do not use GLXgears as a benchmark. It isn't an OpenGL benchmark. It uses such a tiny geometry and screen size that, really, all it's measuring when you run it on a local display is the CPU speed and bus bandwidth. And the results have absolutely no meaning in a remote display setting. I mean, 27,000 fps?! What does that even mean?! Most people can't perceive more than 30 fps and definitely no more than 60. Secondly, always disable frame spoiling (vglrun -sp) when running benchmarks in VirtualGL. Otherwise, you are just measuring how fast VirtualGL can read back frames on the server, not how fast it can actually send them to the client. (This is all in the VirtualGL User's Guide, by the way.) The correct benchmark to use when measuring frame rates for VirtualGL is: /opt/VirtualGL/bin/glxspheres64 If you want a fair comparison of remote X11 vs. VirtualGL, then I suggest the following comparisons: Run this in Remote X11: /opt/VirtualGL/bin/glxspheres64 -m Run this in VirtualGL: vglrun -sp /opt/VirtualGL/bin/glxspheres64 -m > X11 forwarding (no virtualgl): ~4500 - ~11000 > here the window stays black. Might that be related to the remote > GLX implementation being nvidia and the local is AMD? If I test > with another NVIDIA client, it doesn't work at all, failing with > X Error of failed request: BadValue (integer parameter out of > range for operation). Is that expected behavior? Obviously diagnosing bugs in remote display solutions that don't use VirtualGL is out of scope for a VirtualGL support list, but I can tell you that, yes, it's entirely possible that this is due to a mismatch in client vs. server GLX. It is unclear from your description whether you are using SSH to forward X11, but if so, that could be the issue as well. SSH won't let you forward certain X extensions (including GLX) unless you establish the connection with 'ssh -Y' instead of 'ssh -X'. > Anyways using VirtualGL with the different compression types yields: > > proxy (X11): ~240 (with 370Mb/s of the 1000Mb/s LAN connection used) > > rgb: ~3300 (880Mb/s used) > > jpeg: ~3100 (110Mb/s used) > > xv: ~19300 BUT the client window stays black again. What can be > reasons for this, and can I expect such a framerate realistically > in case it works (on a high bandwidth connection)? Again, the frame rates in GLXgears are completely bogus. Use a real benchmark. You may be running into the same SSH permission issue with XV as described above, so try 'ssh -Y'. However, please note that the XV Transport is not intended for remote usage. It was developed for the (now discontinued) Sun Ray ultra-thin client, which included an X proxy (called the Sun Ray Server Software or SRSS) that supported the X Video extension as a means of sending pre-encoded YUV frames through the Sun Ray Server and to the client without the server re-encoding them. The idea was that you would run VirtualGL and SRSS on the same machine. For remote usage with the VGL Transport, you want to use YUV encoding instead. It is similar, but it delivers the encoded YUV frames using the VGL Transport and displays them using X Video on the client side. I really do recommend JPEG, though, as the best means of delivering frames in VirtualGL. We're using libjpeg-turbo, which accelerates JPEG encoding/decoding by as much as 5x relative to libjpeg. > yuv: does not work, failing with > [VGL] ERROR: in operator=-- > [VGL] 437: Invalid compression type > Any idea what's happening there? > > I want to know wether these are reasonable rates/limitations, > especially the jpeg transport which seems CPU-bound (using 140% cpu > in top). Increasing -np did not change anything significantly. JPEG probably will be CPU-limited on a fast network, but you're also seeing a lot of unnecessary CPU time because you're running an unrealistic benchmark. Ultimately, the goal of remote display is to produce a solution that the user perceives as local, so really the whole "local vs. remote" comparison isn't valid. If the application generates 50 fps locally and 30 fps remotely, to the user it's going to be perceived very similarly, as long as the 3D rendering keeps up with the mouse movement (which is why the VirtualGL frame spoiling feature exists and why it should always be used with an interactive application but never with a benchmark.) Also, bear in mind that, when using a real application, the server won't be spitting out frames all the time. We have deployments of hundreds of users in various organizations/companies worldwide, and generally these larger deployments are able to provision 2 or more users per CPU core, although it's important to note that not all users will be actively using the server at the same time, nor will any one user be banging away on it 100% for the whole time they are using it. Let me simplify it-- ultimately, what you want is "local-like" performance. You can probably achieve that on a gigabit pipe using either RGB or YUV encoding with the VGL Transport, but on 100 Mbit or less, you will absolutely never get more than a few frames/second unless you use JPEG. The difference between JPEG and RGB or YUV on a 100 Mbit pipe will be the difference between 50 Megapixels/second and 3-5 Megapixels/second. > Also, what is the preferred way of contributing, just send patches > here? I had to fix some stuff in the build system as well as the > scripts to get everything up and running. If you're just talking about one or two patches, then you can send patches to the virtualgl-devel list. Otherwise, please create a SourceForge patch tracker item. What specifically wasn't working? Bear in mind that a bunch of companies and research institutions are building/testing VirtualGL actively, so if there was anything major wrong with the build system, it would have surfaced before now. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
