On Thu, 05 Mar 2015 15:33:13 -0600 DRC <dcomman...@users.sourceforge.net> wrote:
> On 3/5/15 5:55 AM, Patric Schmitz wrote: > 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. ... > > 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.) Well my intent was actually to get a benchmark of the VGL transport and not the rendering performance, so that's fine. Didn't get the part about frame spoiling though, that's of course what I actually want to measure. And now I also found the section in the manual, thanks for the hint! > > 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'. I was using -Y so I suspect it is the different GLX versions. Will try with a machine sharing the same hardware and driver versions and see if it works from there. > > 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. I see, this is on a very fast network so YUV might be an option. Any idea about the issue above? > ... > 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. Thanks for the clarification. > > 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. Well the Gentoo ebuild as well as the Arch Linux package deploy the package as usual below the /usr hierarchy. There were some hardcoded /opt pathes in the cmake files as well as the scripts themselves which needed to be made a bit more generic. Also for some reason I had to supply the absolute paths for the .so names in LD_PRELOAD, I am not sure why yet, but I will find that out. Is there any particular reason why you chose to deploy stuff in /opt instead of with any other regular package below the /usr hierarchy? FHS says on opt "This directory should contain add-on packages that contain static files". So the question would be why virtualgl is considered an "add-on" package. Normally this is used for 3rd party (ie not belonging to the distro) tools which are kind of self-contained folders not split up into bin/ include/ lib/ etc. But since the cmake install goes nicely in that fashion one might consider dropping the /opt specialities altogether. Well or just make both install locations work more generically. I will send you the patches I needed to do. Thanks for your help! -- Patric Schmitz <bzk0...@aol.com> ------------------------------------------------------------------------------ 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
