Hi Ricky, Given you have 20,000 instances their will and cull and draw dispatch bottleneck. Sharing VBO's won't really share this much. The big elephant in the room is the number of seperate objects to traverse in the cull and draw traversals and the number of seperate GL calls that will have to be made. As you've found batching the data ovoids these bottlenecks and is certainly the way forward.
Robert. On Fri, May 6, 2011 at 9:49 AM, Riccardo Corsi <riccardo.co...@kairos3d.it> wrote: > Hi All, > > Paul, I think I've done some of the benchmark you're referring to on my end > right before starting this thread =) > In my example I replicate the same geometric primitive many times. > The geometric object is a little cube counting 40 vertex and 66 triangles > all rendered as a single drawElements in batch. > I'm using a very basic toon shader to render them, passing vertices, normals > and a vec4 attribute array. > > Here's what I got when I test with 20.000 instances of the primitive when > they are all in the view frustum, > my box is Win7, i7 920 processor, nVidia 285GTX: > > 1) 20.000 separate drawables, each with its own VBO assigned. > CULL: 11ms, DRAW: ~40ms, GPU: ~37ms > Stats are very unstable with this scenario, even when I don't move and with > all of the threading models. > > > 2) 20.000 separate drawables, sharing underneath the same VBO and EBO (at > least I hope I'm doing it the right way, check the code in my previous post) > CULL: ~8ms, DRAW: ~36ms, GPU: ~35ms > > > 3) A single geode+geometry in which I combine all of the instances, rendered > in a single VBO + EBO > CULL: 0.04ms, DRAW: 0.18ms, GPU: ~4.5ms > Stats very stable, no differences among threading models. > With this scenario the fragment opeations becomes the bottleneck when I look > at the scene from a viewpoint that cause all the geometries to be rendered > almost back to front, so that nothing is culled nor discarded by z test. > > So scenario 3 provides a huge boost as expected, while the difference > between 1 and 2 is not as evident as I had hoped... > > I'll see if I'm able to to patch the osg code to achive what Robert > suggests. > > Thanks, > Ricky > > > > > > On Thu, May 5, 2011 at 20:47, Robert Osfield <robert.osfi...@gmail.com> > wrote: >> >> HI All, >> >> >> Current the OSG does unbind VBO's at the end of >> osg::Geometry::drawImplementation(..) so that VBO and EBO state >> doesn't leak into adjoining Drawables. If an implementation is known >> to only use VBO's, with no display lists then potentially we could not >> bother with the unbind at the end of Geometry::drawImplemenation() and >> use lazy state updating. >> >> Robert. >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
