[osg-users] Maximizing rendering throughput

[Robert Milharcic]

On 23.10.2015 13:46, Robert Osfield wrote:
> Hi Robert,
>
> On 23 October 2015 at 12:36, Robert Milharcic <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.
>
Hi Robert Osfield,

Thank you very much for the more in-depth explanation. I pretty sure that this additional info can benefit Sebastian and others as well(including me).

Cheers,
Robert Milharcic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20151023/629a3361/attachment-0003.htm>