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
czw., 6 gru 2018 o 21:36 Ravi Mathur <ravid...@utexas.edu> napisał(a):
> 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
> stats using:
> > .\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
> 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
