Hi All, Last week I introduced a new threading model in osgViewer::Viewer that allowed the draw thread to run in its own graphics thread, with the cull running in a parallel with this. The implementation last week had the cull running as part of the main thread, but I called it ThreadPerCamera last week as I had plans to make the cull run with its own thread too.
Over the weekend, yesterday I wired up the the threading of cull and hoped to get further gains in performance on my dual core/dual GPU system beyond what having cull in the main thread achieved last week. Alas what I have found is that the poor dual core CPU can't manage 5 threads running at the same time all doing stuff required for each frame, the consequence is that things run in series anyway, and not as efficiently as the old ThreadPerContext or just having the main thread do both Camera's culls. This isn't too surprising a finding given I only have two cores. This threading model is clearly waiting for a machine capable of taking full advantage of it, a quad core system is required, AMD/Intel??? Care to send me one :-) Ok so a the above is a bit of background. Now I have fleshed out the implementation of the various threading models I now want to consolidate this work it something end users can use and understand. There are four current threading models now on the table: 1) Main thread does the whole frame, event, update, cull and draw. You'll be familiar with this as SingleThread, both in osgProducer and osgViewer. 2) Main thread does event, update, while a cull-draw pair runs on each context. This mode was called ThreadPerContext in osgViewer, and was effectively ThreadPerCamera in osgProducer/Producer (when one camera per context existed). 3) Main thread does event, update and all camera culls, while draw run on each context. The is the new mode I introduced last week, I called this ThreadPerCamera, but it isn't really as cull wasn't yet threaded. 4) Main thread does event, update, one of the camera and the rest of the camera culls run on a seperate camera thread, and the draws run on separate graphics thread per context. This was where I was heading last week, and now implemented, so is proper ThreadPerCamera (plus ThreadPerContext). Now the names are all getting a bit mixed up, all the extra options for threading have thrown up the need to clearly discriminate between them, and make each model clear as to what it does. My best naming I've come up with so far for the above 4 thread options is: 1) SingleThreaded - this is an easy one ;-) 2) RenderingThreadPerContext or CullDrawThreadPerContext 3) DrawThreadPerContext 4) CullThreadPerCameraDrawThreadPerContext Does this make sense given the above? Is an long winded name for option 4 sensible? Also on the table is an AutomaticSelection option that defers the choice to the realize() implementation to choose what threading model is most appropriate given the hardware and camera/graphics windows setup. Any better suggestions? Which of option 2 works better for you? Thanks, Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
