Robert, Wojciech, Thank you for the advice, this is pretty much exactly what I discovered after some further research. This particular code is pretty old, and I've now re-factored it to use indexed tri-sets instead of tri-strips and things are much better.
While digging, it looks like there are several ways to optimize vertex arrays for the caches on various GPUs...have you looked at all at this? Are there any reasonable rules-of-thumb for organizing the vertex arrays such that they make efficient use of the vertex cache across a wide swath of commodity hardware? Both NVIDIA and ATI have published advice on the topic. sean _________________________________________________________ Sean Spicer Aqumin (www.aqumin.com) Office....+1.713.781.2121 Mobile...+1.713.447.2706 Fax.......+1.713.781.2123 On Sun, Dec 19, 2010 at 6:20 AM, Robert Osfield <[email protected]> wrote: > Hi Sean, > > In general when moving from display listed data to VBO's it's best to > avoid using tri-strips with separate osg::DrawElements and instead > using a single osg::DrawElements containing just GL_TRIANGLES. This > will be more duplicated indices but far less overhead in set up and > dispatch. > > With modern graphics hardware and API the biggest overhead is > typically the dispatch rather than vertex load on the GPU. Even mid > range GPU's can comfortable handle a million+ vertices per frame at > 60hz, but... you have to pass the data to them efficiently, and the > bottlenecks we were once familiar with have changed. > > Robert. > > On Fri, Dec 17, 2010 at 6:57 PM, Sean Spicer <[email protected]> wrote: >> Robert, >> >> Some more data... >> >> Looks like we're drawing approx 100K tri-strips every frame. The >> glDrawElements call is the culprit...though I'm still baffled by why >> it is so much slower with VBOs than in immediate mode. Perhaps the >> drawing isn't sorted by VBO so that all of the triangles drawn from >> each VBO are draw in single bind call ? >> >> sean >> _________________________________________________________ >> Sean Spicer >> Aqumin (www.aqumin.com) >> Office....+1.713.781.2121 >> Mobile...+1.713.447.2706 >> Fax.......+1.713.781.2123 >> >> >> >> On Fri, Dec 17, 2010 at 11:37 AM, Sean Spicer <[email protected]> wrote: >>> Hi Robert, >>> >>> We are not updating the data frame-to-frame, which is why this is so >>> baffling. I'm working through the issue with gDebugger now - if you >>> don't have any suggestions off the top of your head, then I'll start >>> digging and report back what I find, since I don't have time try and >>> duplicate the issue outside our app. >>> >>> cheers, >>> >>> sean >>> _________________________________________________________ >>> Sean Spicer >>> Aqumin (www.aqumin.com) >>> Office....+1.713.781.2121 >>> Mobile...+1.713.447.2706 >>> Fax.......+1.713.781.2123 >>> >>> >>> >>> On Fri, Dec 17, 2010 at 2:36 AM, Robert Osfield >>> <[email protected]> wrote: >>>> reproduces the problem you are seeing? >>>> >>> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
