[osg-users] [About VertexArrayObject Branch] FeedBack and Insight

[Robert Osfield]

Hi Julien et. al,

On 14 August 2016 at 23:21, Julien Valentin <julienvalentin51 at gmail.com> wrote:
> Recently Robert opens a new branch for the integaration of VAO in osg.

To check it out have a look at the VAO branch:

  git checkout vertex_array_object

Then rebuild the OSG,  To enable use of VAO you can set the a new env
var OSG_VERTEX_BUFFER_HINT to VAO.  i.e.

  export OSG_VERTEX_BUFFER_HINT=VAO
  osgviewer cow.osgt


The approach I have taken is to have one Vertex Array Object per
osg:Drawable and not share them.  Design and speed wise I feel this is
the best balance as the OpenGL VAO is intended to make setting vertex
arrays lightweight, since the OSG set's arrays within osg::Geometry
then the natural affinity of VAO is to sit alongside the existing
vertex array calls.  You don't share vertex array set up between
osg::Geometry so there is no need to force sharing of VAO's, they can
happily just sit there a be used when enabled but otherwise ignored.

What could be an advantage to share is the Vertex Buffer Objects's
between osg::Geometry.  This is already possible (on OSG-3.0 onwards)
if you assign the osg::VertexBufferObject and osg::ElementBufferObject
to the osg:Array and osg::PrimitiveSet before hand rather than rely
upon the osg::Geometry to assign it's own.  The new VAO support in the
vertex_array_object branch still supports this so you can share VBO's
between osg::Geometry, while each osg::Geometry has it's own VAO.

The design I have gone for takes into account the need for the feature
to work with existing codes as much as possible without adaptation.
This hasn't been trivial to do, I don't know yet how close I am to
this goal but I've got the majority of the OSG working well.  Wider
testing out in the community will reveal how well it's working.

Performance wise, In city model I'm used for testing the I'm seeing up
to a 30% boost in framerate when comparing VAO+VBO's vs VBO's.  Alas
DisplayLists are still king for this model, looks like NVidia drivers
do a great job in optimizing display lists even today.  The city model
I'm testing has lots of separate osg::Geoemetry, with the model
originally loaded from OpenFlight.

>
> I've thrown a fast look at it,but have not tested yet  -not enough HD space:/ so I can't give a full feedback
> I can only compare with my own impl with this reduced perspective, I don't understand all so don't be regardant if i misunderstood the code.
>
> In my implementation:
> -I assumed the only way to fully take care of the performance bonus of VAO in osg was to share BO among geometries.
>  I use a singleton to manage bo sets involved in vaos, it concatenates bufferdata in these bo and so bos and vao are shared among geometries
> -However concatenate arrays in a bo brings a problem of offset in bo so i have to quit glDrawElementsXXX to glDrawElemntsXXXbasevertex
> So each arrays of a geometry must have the same start index in the bufferobjects and geometries should share the same bo set as often as possible
>
> I did a test in debug build (on a GTX640) with a triangle indexed city and the default useVBO
> it originally frames at 40FPS
> +adding bo sharing among geometries : 55FPS
> +adding useVAO 70FPS (The Draw charge drops from 12 to 6 even if i unbind vao after each geom draw)
>
> https://github dot com/mp3butcher/OpenSceneGraph
>
> In the current branch:
> -I like the idea of deporting vao in state..It seams a good place for them for state sorting.
> -But I haven't spot the way intended to share VAO among Geometries:
> *bo affectation to geoms is not managed (so do we have to assume user is in charge of sharing bo correctly among geoms?)
> *it seams primset doesn't take the way of basevertex draw calls so I'm asking myself how could we manage basevertex when geoms arrays share same bos
>
> I opened this thread, in order others can share their point view on the subject. What do you think of the current branch? How do you see the vao integration in osg? Which approach should be the flexier

When going from the approach I took with the vertex_array_object
branch I reviewed your and other previous VAO approaches but felt they
wouldn't quite meet the requirements.  I feel sharing VAO between
osg::Geometry is not a good design/performance solution, lots of pain
and I'm doubtful of a gain that can justify the extra complexity.
VAO's are lightweight objects in OpenGL, having lots of them is cheap
and makes the cost of vertex array dispatch much cheaper.

For testing you really have to compare performance in a release build
as a debug build adds a huge overhead to cull and draw dispatch.

Robert.