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?


osg-users mailing list

Reply via email to