Hi Julien, Thanks for the link to the model. I've tried it on my iCore7+Geforce760 system and get 113fps with VBO, 130fps with the VAO implementation in the vertex_array_object branch.
I would agree it's not a good model for testing, it doesn't have any textures, the buildings are unrealistic in layout, nothing close to what a real city looks like. I haven't looked at how the scene graph is structured so can't comment on how well it's structured. Unfortunately I can't shared the city models. As a general note, the final VAO implementations has to work well across a wide range of usage models, ideally work better in all situations. So far the vertex_array_object branch looks to be better than using VBO for all the models I've tried, but how much different depends upon the model, the more separate geometries there are the greater the advantage that the VAO has. Have you tested the vertex_array_object branch implementation on your models? Robert. On 16 August 2016 at 23:53, Julien Valentin <julienvalenti...@gmail.com> wrote: > I wanted to give us a common test scene so I seek on blendswap an found > bigcity by chriddi1 I converted to ive > https://drive.google.com/file/d/0BxIH-jcsgYDdTG5ha21HZE1jX1E/view?usp=sharing > > However benchmarks I've done with this scene doesn't exhibit the same gaps in > performance I had with my other scene :( > I only noticed few gain in draw stage with my differents scenarii: > Shared BOs no VAO:8 > Shared BOs 1VAO/Geom:10 > Shared BOs Shared VAOs:6 > All runs at 90 FPS on my GTX640:/ > Perhaps this scene is not fitted for this test...My guess is it's because it > has been excessively fragmented (too much small geoms)..A scene with a wider > variety of index sizes would be a far better test subject... > > So sad I can't share the copyrighted scene there's a lot of large building > with variety of shapes (and so index sizes).. > > > > mp3butcher wrote: >> Hi Robert >> I would rather you to give the test scene for benchmark, mine is >> not-by-me-copyrighted >> An you're right in my VAO system I have to force reaffectation of >> bufferobjects when useVertexArrays is set (in order to be drawable without >> basevertex drawcall) to false and doing so i discard user bos, and this is a >> bad... >> however if I'd force the use of basevertex draw call in all cases It >> wouldn't be necessary >> >> >> > adding an extra layer of complexity is something that most users would >> > really struggle with. >> > >> >> I don't understand what you refer to with this sentence...my only user >> interface is the usevertexArrayObject flag..?! user don't have to know about >> underlying stuff as the bo affectation pattern is the only fitting osg (no >> interleaved case) >> >> >> >> robertosfield wrote: >> > Hi Julien, >> > >> > On 16 August 2016 at 18:37, Julien Valentin <> wrote: >> > >> > > Hello all >> > > @scraw : geometries doesn't have to share vertex arrays but >> > > bufferobjects..this is not the same: >> > > The pattern that maximize vao reutilization is the followed >> > > Geom1 >> > > G1VertAttrib1->BO1 G1VertAttrib2->BO2...and a Unique IndexArray->BON >> > > Geom2 >> > > G2VertAttrib1->BO1 G2VertAttrib2->BO2...and a Unique IndexArray->BON >> > > >> > > With this pattern and vao sharing I have not only draw stage drop but >> > > also a huge gpu charge decrease >> > > The only problem is that you should use glDrawXXBaseVertex or >> > > offsetIndices of your IndexArray >> > > >> > > My bench in release this time >> > > .............................................................. Cull >> > > Draw GPU FPS >> > > Pattern on all geometries with 1VAO/Geom 2 4 >> > > 1.37 160 >> > > Pattern on all geometries with shared VAOs 2 2 >> > > 0.47 200 >> > > >> > > So I think there's interest in sharing vaos >> > > >> > >> > If you have a usage case please create an example that we can share >> > and use when benchmarking. >> > >> > FYI, The VertexArrayState class that wraps up vertex array dispatch >> > and vertex array objects when enabled is capable of enabling sharing >> > between osg::Drawable. In fact it's possible to share a single >> > VertexArrayState between the whole scene graph just relying upon the >> > VertexArrayState object in osg::State. When VAO is not enabled >> > osg::State maintains a single VertexArrayState object that handles all >> > the vertex array dispatch. >> > >> > Currently I haven't exposed the local osg::Drawable VertexArrayState >> > object as publicly accessing able in osg::Drawable but this could be >> > done easily. I'm not yet convinced that this is good idea and don't >> > yet know of the consequence that might unfold. >> > >> > Please remember the VAO system has to work well with the non VAO >> > usage, performance overheads have to be kept to a minimum and the >> > usage for end users has to be kept simple, adding an extra layer of >> > complexity is something that most users would really struggle with. >> > >> > Robert. >> > _______________________________________________ >> > osg-users mailing list >> > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > >> > ------------------ >> > Post generated by Mail2Forum >> > [list=][/list][/list] > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=68398#68398 > > > > > > _______________________________________________ > 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