For starters, GLXgears is not a GPU benchmark. It is a CPU benchmark, because its geometry and window size are so small that its frame rate is almost entirely dependent upon CPU overhead. Please (and I'm saying this to the entire 3D application community, not just you) stop quoting GLXgears frame rates as if they have any relevance to GPU performance.
GLXspheres (which is provided with VirtualGL) is a much better solution if you need something quick & dirty, but you also have to understand what it is you're benchmarking. GLXspheres is designed primarily as an image benchmark for remote display systems, so it is meant to be limited by the drawing speed of the remote display solution, not by the 3D rendering speed. On the K5000 that nVidia was kind enough to send me for testing, I can literally max out the geometry size on GLXspheres-- over a billion polys-- and it keeps chugging along at 300 fps, because it's using display lists by default (and thus, once the geometry is downloaded once to the GPU, subsequent frames just instruct the GPU to reuse that same geometry.) Not every app uses display lists, though, so if you want to use GLXspheres as a quick & dirty OpenGL pipeline benchmark, then I suggest boosting its geometry size to 500,000 or a million polygons and enabling immediate mode (-m -p 500000). This will give a better sense of what a "busy" immediate-mode OpenGL app might do. When your benchmark is running at hundreds of frames per second, that's a clue that it isn't testing anything resembling a real-world use case. In the real world, you're never going to see more than 60 fps because of your monitor's refresh rate, and most humans can't perceive any difference after 25-30 fps. In real-world visualization scenarios, if things get too fast, then the engineers will just start using larger (more accurate) models. :) So why would you use VirtualGL? Several reasons: (1) The approach you're describing, in which multiple 3D X servers are served up with VNC, requires screen scraping. Screen scraping periodically reads the pixels on the framebuffer and compares them against a snapshot of the pixels taken earlier. There are some solutions-- the RealVNC/TigerVNC X.org module and x11vnc, for instance-- that are a little more sophisticated than just a plain screen scraper. They use the X Damage extension and other techniques to get hints as to which part of the display to read back, but these techniques don't work well (or sometimes at all) with hardware-accelerated 3D. Either the OpenGL pixels don't update at all, or OpenGL drawing is out of sync with the delivery of pixels to the client (and thus you get tearing artifacts.) I personally tested the version of x11vnc that ships with libvncserver 0.9.9 (libvncserver 0.9.9 has the TurboVNC extensions, so at the library level at least, it's a fast solution.) I observed bad tearing artifacts for a few seconds, and then it would hang because the X server got too busy processing the 3D drawing and couldn't spare any cycles for x11vnc (X servers are single-threaded.) Turning off X Damage support in x11vnc made the solution at least usable, but without X Damage support, x11vnc is mainly just polling the display, so it will incur a lot of overhead. This became particularly evident when using interactive apps. glxspheres -i I couldn't get the TigerVNC 1.3.1 X.org module to work at all, and the TigerVNC 1.1.0 X.org module (the one that ships with RHEL 6) did not display any pixels from the OpenGL app. (2) The ability to share a GPU among multiple users. VirtualGL installations often have dozens of users sharing the GPU, because not all of them will be using it simultaneously, and even when they are, they might only need to process a small model that uses 1% of the GPU's capacity. Like I said above, a K5000 pipe can process billions of polys/second. That's the equivalent performance of at least a handful of desktop GPUs (if not more) combined. It's a lot more cost-effective to buy beefy servers with really beefy multi-pipe GPU configurations and provision the servers to handle 40 or 50 users. You can't do that if each user has a dedicated GPU, because you can't install 40 or 50 dedicated GPUs into a single machine. (3) Efficiency and cost. VirtualGL and TurboVNC are only going to take up resources when they are running. A full-blown X server has a much larger footprint. The screen scraper will eat up CPU cycles even if the 3D application is sitting there doing nothing, because the screen scraper is having to poll for changes in the pixels. TurboVNC/VirtualGL, on the other hand, will not take up CPU cycles unless the 3D application is actually drawing something. Furthermore, if the user goes to lunch, their GPU is now sitting completely idle. If the user only needs to process a 50,000-polygon model, then their dedicated GPU is being grossly underutilized. On 10/2/14 12:36 PM, Göbbert, Jens Henrik wrote: > Hi VirtualGL, > > I am using virtualGL since some years now to get 3d-accelerated remote > visualization possible via TurboVNC on our frond-nodes of a > compute-cluster via. > > Just recently I was asked why remote 3d-accelerated desktop scenario is > not possible with multiple 3d-accelerated X-servers+VNC, each dedicated > to a single user? > > I cannot answer this question as I would like to, as it seems to run fine: > > We tested to run multiple 3d-accelerated X-servers on the same machine > with a single GPU without any problems. > > glxgears showed 600 frames per second on both at the same time –> both > X-server where 3d-accelerated. > > Why shouldn´t I go for multiple 3D-X-server (one for each user) > > and send its framebuffer via VNC to the workstations > > instead of using VirtualGL? > > Best, > > Jens Henrik ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
