Hi Robert, thank you for your advice, but I used 20.000 only for benchmarking purposes,
I'll balance better the scenegraph in the real application. Even so, with the scenario number 2, I was hoping to achieve performances closer to scenario 3 than 1, as the stats scale quite in linear way with smaller number of drawables. Do you think the approach you suggest, avoiding explicit buffer unbind, would provide some benefit? I also have another question: when assigning vertex attributes and using VBO, I've met some issues using methods Geometry::setNormal/ColorArray and retrieving the related attributes with gl_Normal/Color in shaders, while everything works smooth if I assign and bind specific attribute indices. What is the reason behind it? Thank you, Ricky On Fri, May 6, 2011 at 11:29, Robert Osfield <[email protected]>wrote: > 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 > <[email protected]> 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 <[email protected]> > > 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 > >> [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 >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
