Hi Robert, You won't see an increased framerate for applications that are already GPU-limited. The easiest way to see an improvement is to simulate an expensive cull traversal, see the example in the first post. The OSG cull traversal may not be so expensive by default for a balanced scene graph, but cull callbacks are often used to update animations, lighting or other user tasks so I would consider it important that filling the cull stage with more work scales well. You could also try adding more cameras to see how that scales. Generally I found that in CullThreadPerCamera threading mode without this patch, you very quickly become CPU limited because only the last camera's culling stage can overlap with the rendering thread. DrawThreadPerCamera remedies the problem, but can't spread the culling work across CPU cores.
I guess we have increased latency now because with an earlier frame break, the update and culling threads can jump ahead of the rendering thread further causing more work to be queued up. Unsure how to resolve this. Most users would prefer higher framerates over a small decrease in latency. But then again, higher framerates aren't a given, only if you were previously CPU limited. It's a low priority request anyway - for most OSG users the culling stage will have negligible impact. I am unsure how to fix the increased latency issue, so maybe we should drop the idea altogether. Cheers, Jannik ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65222#65222 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
