Discussion:
[osg-users] Dynamic VBO Performance Drop
Ravi Mathur
2018-12-06 20:35:30 UTC
Permalink
Hello all,

I'm running into a strange performance drop issue when using dynamic VBOs
that change frequently. I am measuring performance using framerate with
vsync turned off. I know that framerate isn't always the best performance
measurement, but my example is simple enough and the performance drop is
significant and repeatable, so I feel comfortable using framerate.

The issue: Suppose I have a Geometry that will hold lots of points (e.g.
100k or more). If I choose to pre-define all points in its vertex array,
then a certain framerate is achieved. However, if I choose to add a batch
of points during each update traversal, up to the same total number of
points, then after all points have been added the framerate is much lower
than in the pre-defined model. Note that "much lower" means over 30% lower.

Note that in both cases, the same number of points are being drawn, and the
Geometry and its vertex array are created once and modified (I'm not
creating new Geometry objects at every update). All that changes is whether
I added the points all at once before rendering or a few at a time while
rendering.

I wrote a small standalone osg example (attached). Compile, run, and show
.\osgdynamicvbotest.exe --numPoints 100000 --batchSize 100000
* If batchSize = 100000 (same as numPoints) then you'll see the case
where all points are pre-defined.
* As you reduce batchSize (e.g. 100), it will take longer to add the
total number of points, but after all points have been added and the
framerate stabilizes, you'll see it is much lower than the pre-defined case
above.

My question is, why is this happening? Is it related to intermediate VBOs
being kept in memory and slowing down the GPU? All the other forum posts I
see on the topic are either about VBOs not displaying properly (not the
case here) or about memory usage (not the case here).

Any thoughts on what's going on here would be very much appreciated.

Thank you!
Ravi
Wojciech Lewandowski
2018-12-10 13:34:57 UTC
Permalink
Hi Ravi,

We usually do not make such extensive checks but we were debuging other
interesting VBO problem so we also checked yours. Few observations.:

0. I noticed you used multithreaded configuration and switched to
SingleThreaded. Multithreaded config creates 2 instances of GL resources
and I thought it may affect your measurments so we continued with
SingleThreaded later.

1. Code line where you set DYNAMIC_DRAW is followed by setVertexArray and
setVertexArray resets this to STATIC_DRAW. You will get better results when
you setUsage after all arrays were defined (like this, note I made
numPoints and batchSize global) :

[...]
geom->setColorArray(lineColors, osg::Array::BIND_OVERALL);
geom->addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::LINE_STRIP,
0, 0));

if ( numPoints > batchSize )
geom->getOrCreateVertexBufferObject()->setUsage(GL_DYNAMIC_DRAW);
else
geom->getOrCreateVertexBufferObject()->setUsage(GL_STATIC_DRAW);
[...]

2. Once we set GL_DYNAMIC_DRAW we see similar performance (on Nvidia GTX
1080 Windows 10) in both versions.

3. So in your code the VBO was always refreshed with GL_STATIC_DRAW. We
suspect that problem is actually related to OpenGL driver memory
management. My friend Marcin Hajder checked the underlying OpenGL calls
with CodeXL and both versions made exactly the same calls per frame after
updates stopped. And buffer and array sizes were the same too. So we
concluded that it must be some memory fragmentation/thrashing issue in
OpenGL driver. This suspicion was somewhat confirmed when we checked the
memory use. When updates stabilized the dynamic version was still taking 10
MB more GPU/RAM than static version. See attached screenshots from
ProcessExplorer. Picture with larger mem use is dynamic, smaller mem use
picter is static version. Note MB usage drop in dynamic version after
minute or so from the moment updates stopped. I suspect driver compacted
the memory when it noticed the resources are no longer updated.

[image: dynamic.png]
[image: static.png]

Cheers,
Hope this helps,
Wojtek Lewandowski & Marcin Hajder
Post by Ravi Mathur
Hello all,
I'm running into a strange performance drop issue when using dynamic VBOs
that change frequently. I am measuring performance using framerate with
vsync turned off. I know that framerate isn't always the best performance
measurement, but my example is simple enough and the performance drop is
significant and repeatable, so I feel comfortable using framerate.
The issue: Suppose I have a Geometry that will hold lots of points (e.g.
100k or more). If I choose to pre-define all points in its vertex array,
then a certain framerate is achieved. However, if I choose to add a batch
of points during each update traversal, up to the same total number of
points, then after all points have been added the framerate is much lower
than in the pre-defined model. Note that "much lower" means over 30% lower.
Note that in both cases, the same number of points are being drawn, and
the Geometry and its vertex array are created once and modified (I'm not
creating new Geometry objects at every update). All that changes is whether
I added the points all at once before rendering or a few at a time while
rendering.
I wrote a small standalone osg example (attached). Compile, run, and show
.\osgdynamicvbotest.exe --numPoints 100000 --batchSize 100000
* If batchSize = 100000 (same as numPoints) then you'll see the case
where all points are pre-defined.
* As you reduce batchSize (e.g. 100), it will take longer to add the
total number of points, but after all points have been added and the
framerate stabilizes, you'll see it is much lower than the pre-defined case
above.
My question is, why is this happening? Is it related to intermediate VBOs
being kept in memory and slowing down the GPU? All the other forum posts I
see on the topic are either about VBOs not displaying properly (not the
case here) or about memory usage (not the case here).
Any thoughts on what's going on here would be very much appreciated.
Thank you!
Ravi
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Loading...