HI Csaba, On Thu, Oct 16, 2008 at 1:29 PM, Csaba Halász <[EMAIL PROTECTED]> wrote: > The other threading models seem to work, and the osg camera example > works with CullThreadPerCameraDrawThreadPerContext too. > I wonder if the problem reported by Paul in the mail thread "Please > test SVN of OpenSceneGraph in prep for 2.7.3 dev release" may be > related to this one. I have been able to reproduce that with an older > nvidia driver, but since I upgraded to 177.80 osgcamera works ok.
I suspect the particular problem you are seeing is not directly driver related, but is an OSG bug, differences in drivers might change the timing slightly which leads to the problem not becoming visible, but may well still be lurking. > If I read the code right, during a frame all threads enter through the > _startRenderingBarrier, then the cull threads do the work while the > matching draw threads are blocked, then finally the draw is done. The > way I see it, one of the draw threads is still blocked waiting for the > cull to happen. I'll try to add some more debug printouts, but I am > still open to ideas :) CullThreadPerCameraDrawThreadPerContext is the most complex of all the osgViewer threading models, and with it the widest range of different thread/barrier combinations. It could be that you are using a combination of cameras/contexts that hasn't been tested before, or simply that the timing of threads in your case breaks the setup. Without being able to reproduce the problem at my end there isn't too much I can do to help out debug it. Could you have a bash at recreating the problem with an existing OSG example such as osgcamera or osgwindows? Robert. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
