[osg-users] Maximizing rendering throughput

[Sebastian Messerschmidt]

Hi Robert,

Thanks for the explanation. I'm still puzzled by the question which 
elements can be updated in the update-phase without setting them to 
dynamic. I always was under the impression, that the update is performed 
before cull/draw are actually executed.
Right now I need some thread safe "time slot" to change the scene graph 
in terms of inserting nodes, updating transforms etc. I guess it is 
totally okay to do this in the update callback/operation.
But for changes to images, text, an arrays of drawables I need to set 
them to DYNAMIC if I understood you correctly. So basically what I got 
is, that I could put the draw of those elements as far to beginning of 
the draw as possible.

As for the double buffering: Can it be done at drawable level? Like 
swapping the front/back drawable back and forth, effectively doubling 
the geometry/image space needed?

Cheers
Sebastian
> Hi Robert,
>
> On 23 October 2015 at 12:36, Robert Milharcic 
> <robert.milharcic at ib-caddy.si <mailto:robert.milharcic at ib-caddy.si>> 
> wrote:
>
>     First of all, I didn't know that cull and draw traversal can
>     execute in parallel on a single scene. I always thought that cull
>     and draw can only execute sequential (serial) in all available
>     threading models. Anyway,  what I know for sure is that update and
>     draw traversal can indeed execute in parallel within some
>     threading models, and that is the reason why we need DYNAMIC
>     variance, to tell drawing thread it must process dynamic elements
>     first, and then immediately allow execution of the update
>     traversal in a main thread while STATIC elements are still being
>     rendered in a draw thread. I also suspect that next frame cannot
>     start before all the static+dynamic elements are rendered. If I'm
>     correct on this one, then few DYNAMIC elements should not affect
>     frame rate at all, because there is plenty of time to do the
>     processing while STATIC elements are still being rendered.
>
>
> With the DrawThreadPerContext and 
> DrawThreadPerContextCullThreadPerCamera threading models the static 
> part of the rendering can be done in parallel with the next frame.  
> You guess this correct.
>
> The one thing I'd add is that the OSG itself doesn't attempt to sort 
> DYNAMIC objects so that are drawn first. You can set up your 
> StateSet::RenderBinDetails to force the dynamic objects to be drawn 
> first, but you can only do this for objects that don't affect the 
> rendering of other objects, or are affected by what is the fame buffer 
> already.
>
> In the case of text it has to be placed in the depth sorted bin which 
> is drawn after the main opaque bin, so if there are text objects set 
> to DYNAMIC then you stop the next frame from start till the end of 
> dispatch of the last depth sorted dynamic object.  This may well be 
> very near the end of the draw dispatch so you come pretty close to 
> nullifying all the capacity for running the draw thread in parallel 
> with the next frames' update and cull traversals.  This is likely the 
> situation for Sebastian.
>
> Using double buffering of Text object's is probably the best way to 
> avoid updating a Text object while it's being drawn, allowing the Text 
> DataVariance to remain STATIC. Such double buffering could be done a 
> custom Node that has two Text objects, one for current frame being 
> updated, and one for the previous frame still being rendered.
>
> Robert.
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20151023/867af755/attachment-0003.htm>