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 <antoinecu...@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@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
