<div dir="ltr"><div dir="ltr">Hi Ravi,<div><br><div>We usually do not make such extensive checks but we were debuging other interesting VBO problem so we also checked yours. Few observations.:</div><div><br></div><div>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. </div><div><br></div><div>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) :</div></div><div><br></div><div>[...]</div><div><div>  geom->setColorArray(lineColors, osg::Array::BIND_OVERALL);</div><div>  geom->addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::LINE_STRIP, 0, 0));</div><div><br></div><div>  if ( numPoints > batchSize )</div><div>    geom->getOrCreateVertexBufferObject()->setUsage(GL_DYNAMIC_DRAW);</div><div>  else</div><div>    geom->getOrCreateVertexBufferObject()->setUsage(GL_STATIC_DRAW);</div></div><div>[...]</div><div><br></div><div>2. Once we set GL_DYNAMIC_DRAW we see similar performance (on Nvidia GTX 1080 Windows 10) in both versions. </div><div><br></div><div>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.</div><div><br></div><div><div><img src="cid:ii_jpicruro0" alt="dynamic.png" width="563" height="456"><div><img src="cid:ii_jpicrurw1" alt="static.png" width="563" height="456"><br></div></div></div><div><br></div><div>Cheers,</div><div>Hope this helps,</div><div>Wojtek Lewandowski & Marcin Hajder</div></div></div><br><div class="gmail_quote"><div dir="ltr">czw., 6 gru 2018 o 21:36 Ravi Mathur <<a href="mailto:ravidavi@utexas.edu">ravidavi@utexas.edu</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hello all,<div><br></div><div>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. </div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>I wrote a small standalone osg example (attached). Compile, run, and show stats using:</div><div>> .\osgdynamicvbotest.exe --numPoints 100000 --batchSize 100000</div><div>   * If batchSize = 100000 (same as numPoints) then you'll see the case where all points are pre-defined.</div><div>   * 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.</div><div><br></div><div>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). </div><div> <br></div><div>Any thoughts on what's going on here would be very much appreciated.</div><div><br></div><div>Thank you!</div><div>Ravi</div></div></div>
_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</blockquote></div>