A lot of what I posted here is just a more nuts-and-bolts version of the same information that is provided in the background article:
http://www.virtualgl.org/About/Background The nuts and bolts change over time, and I don't really want to have to re-write that article every time they do. The basic 10,000-foot managerial explanation has not changed in 10 years, and it's basically this: VirtualGL enables multi-user GPU sharing/load balancing, whereas the screen scraping/dedicated GPU approach doesn't. On 10/3/14 12:13 AM, Göbbert, Jens Henrik wrote: > Hi VirtualGL, > > thanks for your detailed answer - we searched, but could not find a good > explanaition like this: > >> 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. > > best, > Jens Henrik > > P.S.: You might want mention the 'screen scraper'-approach in the > documentation/introduction/wiki and compare it with VirtualGL. > > ________________________________________ > From: DRC [dcomman...@users.sourceforge.net] > Sent: Thursday, October 02, 2014 10:26 PM > To: virtualgl-users@lists.sourceforge.net > Subject: Re: [VirtualGL-Users] virtualGL vs. multiple remote 3D X-servers > > 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 > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > ------------------------------------------------------------------------------ > 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 > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > ------------------------------------------------------------------------------ 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 VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
