Is it safe to read/render (not modify) OSG scene graph from multiple threads?

[Igor Baidiuk]

Hello!

Does anyone know if it's safe to render OSG scene graph on one thread and walk it with read-only visitor and/or read node properties (**not** modify) on another thread?

I'm using OSG with GUI framework which utilizes off-thread rendering. Qt's QML to be more specific. Main GUI thread may read scene graph, to perform raycast selection for example. Render thread may walk scene graph to perform rendering at the same time. Scene graph may be modified **only** at the point where both threads are synchronized with mutex. QQuickItem::updatePaintNode method override, to be more specific.

Thanks,

Igor

[Robert Osfield]

Hi Igor,

The OSG is built for multi-threading of osgViewer View's in various ways, it's not general multi-threading support, it's designed specifically for a scene graph so overheads for that multi-threading to a minimum. 

The multi-threading that osgViewer provides is managed by osgViewer itself so it can marshal all the tasks and synchronization correctly.  Doing the threading a synchronization externally should be possible with limitations to work similar to how osgViewer works, however, it won't be straight forward.  My recommendation would be to work with the VSG's existing threading.

If you want to attempt to do all the threading yourself via Qt then personally I'll need to step back and let you get on with it, trying to do it work suck too much of my time, for something that might not work out, and would be of little general benefit to the community, and I have no Qt expertise to guide the process.

Cheers,

Robert.

[Igor Baidiuk]

Hi Robert,

Thanks for your answer. Although I believe you misunderstood my question in some aspects.

First, I'm working with OSG, not VSG. And AFAIK OSG's threading model is quite limited - because OpenGL doesn't support any kind of multithreaded rendering.

Second, I mentioned Qt/QML to simply be more specific. I don't expect you or anyone else to help me with my work or tweak OSG somehow.

Third, the question itself isn't that specific IMO to Qt. It's a situation where scene/UI rendering is performed on a separate thread, which is synchronized with main UI thread on each frame. My code ensures that scene graph is mutated in any way only at that specific synchronization point. My only issue is that I need to perform ray picking (or some other minor read accesses) over scene graph on main UI thread while scene may be rendered on render thread at the same time. If rendering mutates some parts of scene graph internally, then I may have issues. If not, then I'm good.

Thanks,

Igor

[Robert Osfield]

Hi Igor,

On Wed, 19 May 2021 at 08:37, Igor Baidiuk <ibai...@amcbridge.com> wrote:

Thanks for your answer. Although I believe you misunderstood my question in some aspects.

First, I'm working with OSG, not VSG.

Actually, I mistyped the single reference to VSG, I meant to type OSG.  My whole reply related to just the OSG.  My main focus these days is the VSG so I can type it automatically without realizing.  Sorry for the confusion.

 

And AFAIK OSG's threading model is quite limited - because OpenGL doesn't support any kind of multithreaded rendering.

OpenGL only supports thread per context, so each context can only be driven by a single thread at any time,  The OSG's viewer threading is built around this constraint.

 

Second, I mentioned Qt/QML to simply be more specific. I don't expect you or anyone else to help me with my work or tweak OSG somehow.

Third, the question itself isn't that specific IMO to Qt. It's a situation where scene/UI rendering is performed on a separate thread, which is synchronized with main UI thread on each frame. My code ensures that scene graph is mutated in any way only at that specific synchronization point. My only issue is that I need to perform ray picking (or some other minor read accesses) over scene graph on main UI thread while scene may be rendered on render thread at the same time. If rendering mutates some parts of scene graph internally, then I may have issues. If not, then I'm good.

Principally the rendering threads (cull and draw) don't write to the scene graph, they just read from it.  There are a limited number of exceptions where nodes are view dependent and cache state within the node.  This means it should be safe to run an intersection traversal at the same time as the viewer.renderingTraversals() is running.

Cheers,

Robert.

 

[Igor Baidiuk]

Thanks. I guess this answers my question.