[osg-users] Render to texture race condition

[Nicolas Baillard]

Hello everyone.

I have a view with a master camera rendering to a texture. Then I have two slave cameras that display this texture into two different windows (so two different rendering contexts). When I use the DrawThreadPerContext threading model I get a crash into Texture::TextureObjectSet::moveToBack(). My investigation on this crash makes me believe it is caused by a race condition on the texture generated by the master camera : one context is rendering into it while another is using it.

Does OSG provide any synchronization mechanism I could use to prevent that ?

Regards,
Nicolas

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=62761#62761





_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Robert Osfield]

Hi Nicolas,

The OSG by default will use separate OpenGL objects and associated buffers for each graphics context.  If you enable sharing of GL objects between contexts then you'll need to run the application single theaded to avoid these shared GL objects and associated buffers being contend.

If it's neither of these issues then try the latest version of the OSG.

Robert.

[Nicolas Baillard]

Thank you Robert.

By "sharing of GL objects between contexts" I assume you mean the sharedContext member of the GraphicsContext::Traits structure correct ?

I do set this member for all my contexts. If I don't set it then my windows don't display the texture generated by my master camera, they display an uninitialized texture instead.

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=62763#62763

[Robert Osfield]

Hi Nicolas,

On 23 February 2015 at 09:35, Nicolas Baillard <nicolas....@gmail.com> wrote:

By "sharing of GL objects between contexts" I assume you mean the sharedContext member of the GraphicsContext::Traits structure correct ?

Yes, this is how one sets up shared contexts.  This means you'll need to run SingleThreaded or drop the shared contexts.

The OSG doesn't mutex lock GL objects for a single context as the costs would be prohibitive, and it's only required for shared contexts usage so it's not a penalty that is worth paying.

 

I do set this member for all my contexts. If I don't set it then my windows don't display the texture generated by my master camera, they display an uninitialized texture instead.

You don't provide any information about the set up of the Cameras and render order so there isn't any way for others to be able to guess the cause of this. 

I would suggest fixing this problem, or just go with shared contexts and SingleThreaded.

Robert.

 

[Nicolas Baillard]

robertosfield wrote:
> The OSG doesn't mutex lock GL objects for a single context as the costs would be prohibitive, and it's only required for shared contexts usage so it's not a penalty that is worth paying.

If I didn't use render to texture at all (or if I didn't try to share the generated textures between the contexts) then would it be safe to use DrawThreadPerContext and context sharing ? Or could it cause other issues ?

robertosfield wrote:
> You don't provide any information about the set up of the Cameras and render order so there isn't any way for others to be able to guess the cause of this.

My master camera (the one rendering to texture) is set to PRE_RENDER. The render target implementation is set to FRAME_BUFFER_OBJECT but using other implementations doesn't seem to change a thing. It is linked directly to the main scene (using View::setSceneData()).

My two slaves cameras that are displaying the generated texture are both set to POST_RENDER. They are linked to a single Geode with a single drawable attached to it and using the generated texture.

Also, both the Texture2D instance holding the generated texture and the drawable have their data variance set to DYNAMIC.

Do you see any obvious mistake in this ?

Anyway, thank you very much.

Regards,
Nicolas

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=62783#62783

[Robert Osfield]

On 23 February 2015 at 13:09, Nicolas Baillard <nicolas....@gmail.com> wrote:

robertosfield wrote:
> The OSG doesn't mutex lock GL objects for a single context as the costs would be prohibitive, and it's only required for shared contexts usage so it's not a penalty that is worth paying.

If I didn't use render to texture at all (or if I didn't try to share the generated textures between the contexts) then would it be safe to use DrawThreadPerContext and context sharing ? Or could it cause other issues ?

You can't use DrawThreadPerContext when sharing contexts except when your scene graph uses no OpenGL objects whatsoever.  So no display lists, no VBO's, no textures etc.  Basically if you want shared contexts you have to use it SingleThread so the different threads don't contend with the same resources.

 

robertosfield wrote:
> You don't provide any information about the set up of the Cameras and render order so there isn't any way for others to be able to guess the cause of this.

My master camera (the one rendering to texture) is set to PRE_RENDER. The render target implementation is set to FRAME_BUFFER_OBJECT but using other implementations doesn't seem to change a thing. It is linked directly to the main scene (using View::setSceneData()).

My two slaves cameras that are displaying the generated texture are both set to POST_RENDER. They are linked to a single Geode with a single drawable attached to it and using the generated texture.

Also, both the Texture2D instance holding the generated texture and the drawable have their data variance set to DYNAMIC.

Do you see any obvious mistake in this ?

In principle this sounds like it should be OK.  Personally I wouldn't use a master Camera as a render to texture camera.  A slave Camera is probably a better way to do it.  I don't know enough about what you are doing to really know where you are going with it all.  I don't really have the time to go chasing up your implementation.  Please have a look at the OSG examples for render to texture to see how they manage things.

Robert.