Jan, > Thank you very much for all the responses. > I figured it wasn't an multithreading problem, since it also didn't run > if only called once in a single OS-Thread. > > Hartmut's Idea with the stack-sizes fixed it. > Using > > -Ihpx.stacks.small_size=0x20000 > > wasn't enough, but using an bigger size of > > -Ihpx.stacks.small_size=0x200000 > > it works.
Since using 0x200000 will essentially allocate 1MByte for each HPX thread (which is very wasteful, I'd suggest you increase the stack size just for the action which is executing the failing OpenGL function. You can do this by adding the following macro to your code: // that is what you already have HPX_PLAIN_ACTION(process_context, process_context_action); // this is what you should add, increases stack size for // this action to 0x200000 HPX_ACTION_USES_LARGE_STACK(process_context_action); If you do this you shouldn't need the command line option anymore. HTH Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu > > Thanks again for the fast help. > > Best, > Jan > > > On 21.01.2016 22:11, Lars Viklund wrote: > > On 21/01/2016 18:10, Hartmut Kaiser wrote: > >> Jan, > >> > >>> I'm still working on my parallel rendering project and can't find a > >>> solution for an error for over a month now. > >>> Whenever i call my rendering routine through an action (component- or > >>> plain action), i get a Segfault at glLinkProgram(). > >>> If i call it in hpx_main() as a normal method or through std::async, > it > >>> works fine, so my method is not faulty (correct image, no glErrors). > >>> > >>> I want to call it in a component action to render 16 images on 16 > >>> components of a 16-core node/locality simultaneously, but the > simplified > >>> version of just calling it once on a 1-core locality in a plain action > >>> in the hpx_main() gives the same segmentation fault. > >>> > >>> I know this most likely is an error on the interaction of OpenGL and > >>> asynchronous actions in general, but maybe someone on this list has an > >>> idea or has used OpenGL with HPX. > >> Is OpenGL thread-safe in the first place? If you run an OpenGL function > from > >> inside an action and use more than one core, you might end up calling > into > >> OpenGL concurrently, not sure if that's a problem. > > OpenGL contexts may be made current on any OS thread, but a given > > context may only be current on a single OS thread at a time. > > > > As HPX actions may be dispatched on different OS threads over time, you > > need to be very careful about which OS thread your context is current > > on. > > > > In general when doing concurrency and 3D APIs, you tend to prepare as > > much work as possible in threads without invoking API functions, and > > chew through the deferred work in a dedicated OS thread that has control > > over the context. > > > > While there's shared contexts and shared resources in OpenGL, they have > > a bit of a performance penalty and are not quite the fast-path when it > > comes to driver implementations. Some resources like FBOs and VAOs > > cannot be shared at all. > > > > As a side note on multiple contexts and function pointers for > > extensions, it's technically illegal to share function pointers between > > different contexts, but if you only have one context, you don't need to > > care about that. If you do, you may need to use GLEW-MX or similar > > extension wrangler. > > > >> Another issue could be that you run out of stack-space. HPX threads > have a > >> very limited stack-size by default which is easily overflown. Try > running > >> your app with -Ihpx.stacks.small_size=0x20000 to increase the default > >> stack-sizes used. > > _______________________________________________ > > hpx-users mailing list > > [email protected] > > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users > > _______________________________________________ > hpx-users mailing list > [email protected] > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users _______________________________________________ hpx-users mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
