[osg-submissions] Reuse of context IDs and cleanup of OpenGL resources.

Tue Apr 15 19:02:47 PDT 2008

Hi Robert,

I agree that the test program is forcing the error, but that after all 
is the purpose of a test program. Unfortunately, our application does 
not have as simplistic a design as the test program so calling 
releaseGLObjects on objects removed from the viewer's scene graph would 
be decidedly nontrivial.

Our application deals with multiple scenegraphs, each of which is 
dynamic - subgraphs and textures are added and removed at runtime. 
Additionally, these scenes are displayed in multiple windows that are 
dynamically created and destroyed. We don't destroy subgraphs (or call 
releaseGLObjects on them) when they are removed from the scene because 
they may be multiply instantiated in a single scene, or they may shortly 
be re-added to the scene. When a context is destroyed, knowing which 
objects need to be cleaned up (because they were drawn while that 
context was active) is nearly impossible to determine.

Simply put, dynamic models with instanced subgraphs (or textures, 
shaders, or fonts) shared among dynamic windows is the use case that 
leads to this bug. Are any of these individual usages discouraged by osg 
(or even that usual)? Or is it just the combination?

Mark

Robert Osfield wrote:
> Hi Mark,
>
> Your test program is a pretty esoteric forcing of an error, akin to 
> tricking the osgViewer into not doing the right thing.  The problem is 
> simply fixed by doing a releaseGLObjects() on those objects that 
> you've hidden from the viewer.   I'm not convinced we need a more 
> elaborate system just to catch this rather unusual usage model.
>
> Robert.
>
> On Tue, Apr 15, 2008 at 6:31 PM, Mark Sciabica <msciabica at itracs.com 
> <mailto:msciabica at itracs.com>> wrote:
>
>     Hi Robert,
>
>     Running my test program against the 2.3.7 developer release
>     exhibits the same errors as 2.2.0. <http://2.2.0.> Textures and
>     display lists are not being regenerated when a new context reuses
>     a contextID, unless those objects are under one of the Context's
>     cameras when the context is destroyed.
>
>     Mark
>
>     Robert Osfield wrote:
>>     Hi Mark,
>>
>>     The SVN version of OSG has extra support for deleting and
>>     discarding GL object ID's.  I believe this will probably address
>>     the problems you've seen.
>>
>>     Could you move to OSG-2.3.7 or OSG-SVN to see if the problem is
>>     addressed.
>>
>>     Robert.
>>
>>     On Mon, Apr 14, 2008 at 9:55 PM, Mark Sciabica
>>     <msciabica at itracs.com <mailto:msciabica at itracs.com>> wrote:
>>
>>         These changes are a fix for the bug reported here:
>>
>>         http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-January/006048.html
>>
>>          
>>
>>         Briefly, the bug is that objects that allocate OpenGL
>>         resources (e.g. textures or display lists) for a given
>>         contextID believe those objects are still valid even after
>>         the contextID becomes invalid and then reused by another context.
>>
>>          
>>
>>         A source file is attached that reproduces the bug for display
>>         lists, textures, and fonts. Other resource types have not
>>         been tested, although code has been added to clean up all
>>         types that currently clean up their deleted items caches in
>>         the GraphicsContext::close function.
>>
>>          
>>
>>         The modifications were made against the 2.2.0 branch.
>>
>>          
>>
>>         Summary of changes.
>>
>>          
>>
>>         1. ContextData now has a list of objects using OpenGL
>>         resources for its contextID.
>>
>>          
>>
>>         2. Objects using OpenGL resources now add themselves to the
>>         above list when they allocate such a resource, and remove
>>         themselves when they deallocate it.
>>
>>          
>>
>>         3. GraphicsContext::close deallocates the registered
>>         resources if no other contexts are using its contextID.
>>         Calling releaseGLObjects on the camera now seems redundant so
>>         was removed. (Exception: if the _state member of the
>>         GraphicsContext is NULL (which it is when close() is called
>>         more than once(and it is)) then the camera will have its
>>         GLObjects released in ALL contexts. This seems incorrect as
>>         it needlessly releases objects in unrelated contexts.)
>>
>>          
>>
>>         4. ContextData was made an Observer of the objects in its
>>         list to avoid dereferencing invalid pointers if those objects
>>         are destroyed without deallocating their resources.
>>
>>          
>>
>>         5. Static functions that allocate resources and manage a
>>         cache of deleted objects were made nonstatic so they could
>>         register the object with the context at the time the resource
>>         was allocated. They assume the object they're called against
>>         is the object owning the resource. These functions have also
>>         been made protected to help enforce this.
>>
>>          
>>
>>          
>>
>>         Regards,
>>
>>          
>>
>>         Mark
>>
>>
>>         _______________________________________________
>>         osg-submissions mailing list
>>         osg-submissions at lists.openscenegraph.org
>>         <mailto:osg-submissions at lists.openscenegraph.org>
>>         http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>>
>>
>>     ------------------------------------------------------------------------
>>     _______________________________________________ osg-submissions
>>     mailing list osg-submissions at lists.openscenegraph.org
>>     <mailto:osg-submissions at lists.openscenegraph.org>
>>     http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>>
>
>
>     _______________________________________________
>     osg-submissions mailing list
>     osg-submissions at lists.openscenegraph.org
>     <mailto:osg-submissions at lists.openscenegraph.org>
>     http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> osg-submissions mailing list
> osg-submissions at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph.org/attachments/20080415/4c87f286/attachment-0001.htm 