20,741
edits
CompositeViewer support: Difference between revisions
Jump to navigation
Jump to search
→Threading
| Line 186: | Line 186: | ||
easily set up using the native windowing support that the OSG | easily set up using the native windowing support that the OSG | ||
provides.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg16632.html</ref> | provides.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg16632.html</ref> | ||
As long as your run the viewer multithreaded the OSG will use a | |||
barrier so that each graphics thread waits at the end of draw | |||
dispatch, then once all the threads join this barrier then all move on | |||
together and then call swap buffers. This is done to try and achieve | |||
synchronized swapping, however, it's not a full proof scheme as it | |||
doesn't use any low level driver and hardware synchronization. | |||
Extensions to some OpenGL drivers exist to enable the low level | |||
synchronisation, such as swap groups, swap ready and gen lock.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg54571.html</ref> | |||
* osgViewer::CompositeViewer is designed for applications that have multiple Views. The only thing to be careful of is when you are adding and removing View's from the CompositeViewer you should do is calling stopThreading() on the viewer prior to adding or removing views, then call startThreading() afterwards. If you are running SingleThreaded or CullDrawThreadPerContext you won't need to worry about stop and starting threads.<ref>https://groups.google.com/d/msg/osg-users/7OojxLpBGdw/mzorZe3rKwEJ</ref> | * osgViewer::CompositeViewer is designed for applications that have multiple Views. The only thing to be careful of is when you are adding and removing View's from the CompositeViewer you should do is calling stopThreading() on the viewer prior to adding or removing views, then call startThreading() afterwards. If you are running SingleThreaded or CullDrawThreadPerContext you won't need to worry about stop and starting threads.<ref>https://groups.google.com/d/msg/osg-users/7OojxLpBGdw/mzorZe3rKwEJ</ref> | ||
| Line 193: | Line 204: | ||
* as long as you have two GPU's the most efficient way to drive them should be multi-threaded - there is a caveat though, hardware and drivers aren't always up to scratch, and even then they should be able to manage the multi-threads and multi-gpus seemless they fail too.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg18332.html</ref> | * as long as you have two GPU's the most efficient way to drive them should be multi-threaded - there is a caveat though, hardware and drivers aren't always up to scratch, and even then they should be able to manage the multi-threads and multi-gpus seemless they fail too.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg18332.html</ref> | ||
* Cull and draw can only run in a parallel once all the dynamic geometry has been dispatched, otherwise the draw will be dispatching data that is being modified by the next frames update and cull traversals. Perhaps you have some dynamic geometry or StateSet's that are holding back the next frame. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg36238.html</ref> | * Cull and draw can only run in a parallel once all the dynamic geometry has been dispatched, otherwise the draw will be dispatching data that is being modified by the next frames update and cull traversals. Perhaps you have some dynamic geometry or StateSet's that are holding back the next frame. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg36238.html</ref> | ||
* if you are using a single graphics card for best performance one usually tries to use a single graphics window and have two cameras or more share this context.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg54512.html</ref> | |||
The ThreadPerCamera is just shorthand for | The ThreadPerCamera is just shorthand for | ||