[osg-users] Running multiple (independent) viewers in different threads
Robert Osfield
robert.osfield at gmail.com
Fri May 24 06:21:15 PDT 2019
Hi Antoine,
It's not possible to know what is causing the issues with running your
setup from your description, stack trace of the seg fault is the bare
minimum for starting to guess at what might be the issue. It could be
an OSG bug as you are not using the OSG how it's intended or usually
used, or it could be an error in your application, or in the driver.
As a general note, graphics hardware is geared up for massive
parallelism at the vertex and fragment level but, in particular
OpenGL, is less engineered for multiprocessing at the higher level.
Vulkan is better in this respect but still having many graphics
context and associated threads running is going to contend the memory
and buses.
>From your description it may be most efficient to have multiple
threads handling the sim side and have it post requests into a thread
safe queue that is read from the graphics thread and have that
graphics thread deal with all the work in series and send it into the
OpenGL FIFO and when the results are provided then signal the original
requests for rendering. This scheme could keep the OSG/OpenGL side
down to using one graphics context and one graphics thread so this
side most efficiently.
A Vulkan based approach could move more of the work to the original
threads requesting the work as they can build their own
VkCommandBuffers that get submitted into a graphics or compute queue
for dispatch to the processing on graphics/compute on the GPU.
While in theory the VSG work could do the above I haven't attempted
this type of work before and have built into any architecture for it
specifically, longer term this is something it'll support. The VSG is
really just in a alpha state at this point and under heavy development
so I wouldn't yet recommend general adoption, it might be worth
thinking about though if rendering you want to do is quite simple but
very specialized.
If you want to continue using the OSG then I'd recommend the queue
approach, with your creating a high level architecture that abstracts
away the work request from the OSG backend that deals with the work.
Cheers,
Robert.
On Fri, 24 May 2019 at 12:17, Antoine Cully <antoinecully at hotmail.com> wrote:
>
> Dear OSG Community,
>
> I searched quite a lot through the source code and the beginner guide, but I was unable to find a way to make this work, so I am posting here hoping that you could help me.
>
> I am developing a tool to run physical simulations (of robots) in parallel. This tool is used to run stochastic optimisation (like deep reinforcement learning) algorithms, and for this I need to be able to run several, but fully independent, simulations in parallel thanks to multithreading. This enables to collect data faster and for instance with a 32-core multithreaded CPU the speed-up factor is quite significant.
>
> In each simulation, I have one camera that observes the environment, and which can be used to change the behaviour of the robot running in this simulation. The camera is currently implemented as a pbuffer following closely the osgscreencapture example. The actual code of the camera can be found on github, but apprently I am not allowed to post URLs at the moment.
> The multithreading is managed by TBB (an Intel library that I have been using for 6 years now).
>
> If I run my code in a "sequential mode", i.e., all the simulations running one after the other, everything is going well. However, if I run it in parallel, then I have some unstable behaviours. For instance, I can have a segmentation fault happening after a random number of simulations or suddenly after again a random number of simulations, the pbuffer cannot be created anymore (OSG displays "Error: Unable to create pbuffer."). It seems to me that "::osg::ref_ptr<::osg::GraphicsContext> pbuffer = ::osg::GraphicsContext::createGraphicsContext(traits.get()); "
> does not work in this setup.
>
> If I remove the cameras (and all OSG components) from my code, it is working well in parallel, but of course I would like to have cameras in my simulations.
>
> Ideally, I would like to run OSG in a single-thread mode and let TBB distribute the different instances of the simulator and OSG in different threads, but even with "setThreadingModel(osgViewer::ViewerBase::ThreadingModel::SingleThreaded);" it does not work.
> I tried different threading modes, with the same result.
>
> So here is my question:
> What would be the most appropriate way to run several independent viewers and pbuffers, each in a different thread?
> The rendered scenes are really simple (no texture, just several primitive shapes) and I am only rendering a couple of frames in each simulation, so I don't need a complex threading model for OSG.
>
>
> Some information about my system:
> - Ubuntu 18.04
> - OSG 3.6.4
>
> Thank you in advance for your help.
>
> Best regards,
>
> Antoine
>
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=76134#76134
>
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
More information about the osg-users
mailing list