Confirmed in the libGLU source-- slices and stacks are clamped at 240, so 57600 polys per sphere is the max-- very nicely fits your observation (57600 * 61 spheres = 3513600 polys.)
I modified GLXspheres such that it calculates whether this limit will be reached, warns the user, and prints the actual polygon count, taking the limit into account. I also added an option (-n) for increasing the sphere count, which enables polygon counts higher than 3.5 million. For instance: >glxspheres -n 240 -p 10000000 Polygons in scene: 10029456 (241 spheres * 41616 polys/spheres) Visual ID of window: 0x2c Context is Direct OpenGL Renderer: Quadro K5000/PCIe/SSE2 92.948421 frames/sec - 103.730438 Mpixels/sec 95.584804 frames/sec - 106.672641 Mpixels/sec > glxspheres -n 2400 -p 100000000 Polygons in scene: 99920016 (2401 spheres * 41616 polys/spheres) Visual ID of window: 0x2c Context is Direct OpenGL Renderer: Quadro K5000/PCIe/SSE2 10.136359 frames/sec - 11.312176 Mpixels/sec 9.982275 frames/sec - 11.140219 Mpixels/sec Much more along the lines of what I would expect from the K5000 (about a billion quads/second. The press usually reports it at 1.8 billion tris/sec, so that number make sense.) 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. 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
