On 10/2/14 11:44 PM, DRC wrote: > To pop the stack on the original poster's questions, at the OpenGL > level, you can get linear or even super-linear scaling of the GPU > resource among multiple users. If I run 5 sessions of GLXspheres at a > time, each will perform at about 200 million quads/second. If I run 10, > each will perform at about 100 million quads/second. If each user is > working with a 1-million-polygon model, then that's over 30 users at 30 > frames/second. Obviously there will be other constraints on this in a > real-world environment-- VirtualGL and TurboVNC have some CPU overhead > to compress/deliver the 3D images to the client, users might be dealing > with larger models, applications that use a lot of textures won't scale > as well because they'll exhaust GPU memory, etc. However, you're also > not going to have all 30 users banging away all the time. Some of them > will be down the hall, some of them will be reading e-mail, some of them > won't even be in the office, some will be staring at the model and > making small changes rather than manipulating the entire scene.
I should also mention that another constraint you'll have in a real-world environment is reading back the pixels, and you may exhaust your bus bandwidth before you actually exhaust your GPU processing power. But my point is-- people throw quite a few users onto their GPUs. Santos, one of our largest (if not our largest) installations, provisions about 13-16 users per high-end nVidia pipe, although the user workloads vary greatly (oil & gas apps run the gamut of everything from straight 2D X11 all the way to monster 3D visualization.) > On 10/2/14 5:13 PM, Nathan Kidd wrote: >> On 02/10/14 04:26 PM, DRC wrote: >>> 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.) >> >> FYI I recently was testing the theoretical limit on a card and went down >> the path of: >> `glxspheres -p 1000000` "no difference" >> `glxspheres -p 10000000` "hmmm, not breaking a sweat" >> `glxspheres -p 1000000000` "wow" >> >> Then I took a trace and found out that the number of actual ROPs was no >> different between 10 million and 1 billion. gluSphere() apparently hits >> a limit on how much geometry it produces and won't go higher (increasing >> window size didn't do anything; I didn't read the GLU source). >> >> Bottom line: `glxspheres -p 3500000` (which equates to a little over 14 >> millon ROPs per frame) is the highest load the stock glxspheres/libGLU >> will produce. >> >> -Nathan >> ------------------------------------------------------------------------------ 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
