Good morning, On Monday, May 30, 2011 19:54:31 ThorstenB wrote: > On 30.05.2011 19:25, Stefan Seifert wrote: > > The segfault happens when the main loop thread tries to > > access GL information. I know next to nothing about openGL programming > > but I seem to recall that it's not allowed to access the same GL context > > in different threads. So how is this supposed to work? > > Well, wouldn't surprise me to find more related multi-threading issues. > Not sure how long OSG itself supports it, but I guess it wasn't a major > priority at the time when FG was adapted to OSG. And I'm sure more fixes > will be necessary to safely support it. Well, there are several threading issues left in flightgear. Openscenegraph supports threading *very* well since ll tha time I know this project. But flightgear was written initially and has still left plenty of single threading assumptions that are not so easy to remove. I always tried to move into this direction, but never got this into a state where I knew that everything *should* work. I know that some of us regularily play with the threading stuff, And I thought that in the time I have not followed fightgear too close Tim had make that work. But when looking into this, I realize that there is still plenty of stuff to do in this area. Also this explaines various crashes on the LinuxTag booth. If you use multithreading it works in the current state just by accident ...
> The particular source lines also have an "//OSGFIXME" comment - another > hint that work was left behind. Yep... > Try replacing the calls to SGIsOpenGLExtensionSupported - they provide > constant information anyway. It'd be enough to check > version/capabilities once during init and then use constant data at > run-time. Try if that helps. Patches welcome :). Well, this is even more complicated: What happens is that in a multithreaded environment we do *not* have *any* OpenGL context active in the main thread. This means whatever code calls either some of the osg extension query function with a second argument of true or calling the above function can result in undefined behaviour - which is what you experience. Only the draw thread has a opengl context guaranteed. Which makes it immediately clear that the only place where we can reliably call these functions is duning the draw traversal. The osg extension functions take two arguments the first one is the context to ask for, which we currently just hope that all context support the same set of features - which is not true in certain configurations. And the second argument is to really ask for the extensions or use the cached result by just testing against a bool value. On a singlethreaded environment we just have the current thread bound to the current context and everything works magically. But on multiple threaded osg this fails. And depending on the opengl driver it may fail or may not fail ... Also, the mentioned call is relatively slow as it searches a string for a substring where it is in the end mostly a boolean operation to decide if a combination of opengl features is availalbel or not. So if you are in a runtime sensitive code path, don't use SGIsOpenGLExtensionSupported directly. So, what to do: The real solution is hard. Tim effecs code *probably* shows how to solve this. I have never double checked if this is done in a waterproof way, but I would guess this is ... A solution that might at least work for most configurations could be like this: Make sure the splash screen draw already asks for a bunch of extensions in the osg way. Then make sure we do not need the decision before the spash screen is there. Tehn finally use the osg extension query functions with an appropriate second argument to make sure the cached result is taken for this mentioned static initialization time usage in the sky code. Hope this helps a little ... Greetings Mathias ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
