[osg-users] Remove all LOD children
Sebastian Messerschmidt
sebastian.messerschmidt at gmx.de
Sat May 14 01:34:58 PDT 2016
Am 13.05.2016 um 17:28 schrieb Bruno Oliveira:
> I checked with valgrind, and effectively I did not find any memory leak.
>
> The OS System Monitor (Ubuntu, as I said) consistently presents double
> the memory valgrind does (e.g., System Monitor says the app is using
> 2Gb, while valgrind states it is 1GB).
>
> My data (a point cloud) is actually 1GB (binary format). I thought the
> 2GB came from OSG or OpenGL driver keeping a copy of my data for some
> reason.
Yes, because it is totally up to the driver to release this memory. This
should not worry, since this memory is not lost or anything. It is
simply reserved by the driver for possible future allocations and it
will be swapped by the OS if not used.
I haven't seen any problems wiht OSG's memory use so far if the
reference pointers are used in the correct way.
Cheers
Sebastian
>
> 2016-05-13 16:23 GMT+01:00 Alberto Luaces <aluaces at udc.es
> <mailto:aluaces at udc.es>>:
>
> I think some facts must be made clear:
>
> * You cannot control when the OpenGL driver releases the memory it
> claimed in a previous instant.
>
> * You cannot control when the operating system claims back the memory
> pages that a process requested, and in addition, many times it is
> simply not possible to do it due to memory fragmentation.
>
> * At most, what you can do is to check that your program is not
> leaking
> memory with a special tool, as the one I recommended (valgrind for
> CPUs, other tools for GPUs).
>
> System memory tools are completely unreliable for this specific
> purpose.
>
> Bruno Oliveira writes:
>
> > I tried removing the children with m_rootNode->removeChildren(0,
> > m_rootNode->getNumChildren());
> > but this results in some memory being still allocated.
> >
> > After that, I move the mouse around a bit in the clean scene,
> and the
> > memory starts being freed. However, It never gets to the initial
> > value, there is always some memory floating around.
> >
> > 2016-05-13 15:16 GMT+01:00 Alberto Luaces
> > <aluaces at udc.es <mailto:aluaces at udc.es>>:
> >
> > Bruno,
> >
> > if you read the source code, you will see that the LOD uses the
> > same
> > scheme for storing nodes as a Group: just a vector of
> ref_ptr that
> > will
> > be unallocated when destroyed.
> >
> > Maybe you can place some breakpoints at the destructors on the
> > debugger
> > and see what is happening.
> >
> > Bruno Oliveira writes:
> >
> > > Thank you for your answer. However, since I'm using a LOD, I
> > think it
> > > is not properly removing my data. At least the memory is still
> > > allocated.
> > > If I manually iterate over all nodes and delete them by
> myself,
> > some
> > > memory is freed, but not all!
> > >
> > > 2016-05-13 14:58 GMT+01:00 Alberto Luaces
> > >
> > >
> >
> >
> > > Bruno Oliveira writes:
> > >
> > > > At some point I want to completely wipe out my scene.
> How can
> > I
> > > delete
> > > > all nodes?
> > >
> > > If you want to wipe a node and all its descendants, just
> delete
> > > the
> > > parent node. That is what reference counting is all about.
> >
> > --
> > Alberto
> >
> > _______________________________________________
> > osg-users mailing list
> > osg-users at lists.openscenegraph.org
> <mailto:osg-users at lists.openscenegraph.org>
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> >
> >
> >
>
> --
> Alberto
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> <mailto:osg-users at lists.openscenegraph.org>
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
>
> _______________________________________________
> 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/20160514/bf7af681/attachment-0002.htm>
More information about the osg-users
mailing list