[osg-users] TextureBuffer memory not being released from GPU

Robert Osfield robert.osfield at gmail.com
Fri Sep 29 07:44:52 PDT 2017


Hi Tom,

I haven't ever tried to mix TextureBuffer with PagedLOD so can't comment on
the specific of this usage case.

General comments that might help give you an idea of how things works:

 1) The OSG can only release GL resources from a graphics thread, so if you
manually call releaseGLObjects() what actually happens internally is that
the GL objects
      associated with that scene graph object are released from that scene
graph object to a cache of GL objects to be deleted by the appropriate
graphics thread.

  2) The OSG will check these "to be deleted" GL object caches and flush
them on each frame.  There are rules to this mechanism - the rules are
specific to each type
      of GL object.  In general the graphics thread will delete GL objects
for an allocated time period, if this time period is exceeded then it stops
deleting the GL objects
      leaving them for the next frame.  Some GL object types can be reused
by new scene graph elements so this cache might be maintained at a given
size, texture
      vertex buffer objects are examples of this - reusing no longer used
GL objects is far more efficient than deleting GL objecst and then
recreating them.

  3) The DatabasePager works with PagedLOD to load balance, avoiding
deleting of subgraphs and GL objects where possible, instead aiming to keep
a defined amount
      of scene graph and GL objects in memory to be reused, whilst avoiding
exceeding GPU and main memory limits.

This is just skimming the surface on how all the various parts work
together, it's huge topic, discussed lots of the OSG mailing list/forum
over the years so please have a look through the archives on
DatagbasePager/IncrementalCompileOperation and the GL object caches.  I'm
afraid there is lot to take in because of the just how much work has to go
in to making a paging mechanism, work robustly and hit a solid 60Hz with
big databases.

With your use of the TextureBuffer being something I haven't personally
worked on, and how you've deployed it in your application means that I
can't provide much specific advice.   It could be a bug with TextureBuffer,
it could be that your setting up PagedLOD and the rest of the scene graph
with way too high of complexity subgraphs such that it blows the memory of
your system.  The OSG defaults try avoid this but you are doing enough
custom stuff that these may not help you, but might hinder you.

Robert.





On 29 September 2017 at 12:25, Tom Marsland <tom at appsincadd.co.uk> wrote:

> Hi,
>
> I've set up a system using PagedLOD derived classes and the TextureBuffer
> class with draw instancing to render large point clouds stored on disk.
>
> Everything works fine to start with but I've noticed the gpu memory
> increasing as I zoom in and out, unloading and reloading the PagedLOD nodes
> and corresponding texture buffers. Eventually, the GPU memory gets full and
> it slows down a lot as it starts using system memory.
>
> It looks like the memory on the GPU allocated to the texture buffers is
> not freed up, which would be fine if it got cached and reused but it
> doesn't look like this is happening.
>
> I have spent a day or so looking at the source code for the texture
> classes and trying to manually clear the memory but am now a bit stuck! I
> figured that calling releaseGLObjects on the Geometry node or the
> TextureBuffer should clear the data but neither seems to have any effect.
>
> Does anyone have any ideas?
> Thanks in advance!
>
> Tom
>
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=72078#72078
>
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20170929/38383e36/attachment-0001.html>


More information about the osg-users mailing list