[osg-users] user stats update

Robert Osfield robert.osfield at gmail.com
Thu Nov 19 07:20:55 PST 2015


Hi Ricky,

I'm afraid I can't help further there are too many unknowns to provide
guidance.

Robert.

On 19 November 2015 at 14:51, Riccardo Corsi <riccardo.corsi at kairos3d.it>
wrote:

> Hi Robert,
>
> I wasn't able to reproduce the issue with as osg example.
> But I've found that if just set to true the "average" flag when calling I
> addUserStatsLine(), the flickering disappear.
> Don't know if this is helpful, but the result just works for me.
>
> Regarding the drawing stats affected by the driver blocking behavior,
> is the only drawback is a "fake" stats or there might be actual
> performance penalties?
>
> Thanks,
> Ricky
>
> On Wed, Nov 18, 2015 at 8:08 PM, Robert Osfield <robert.osfield at gmail.com>
> wrote:
>
>> Hi Ricky,
>>
>> This type of behaviour can be difficult to diagnose when you have all the
>> data and software in front of you, when you only have reports from a 3rd
>> party it's unfortunately next to impossible to diagnose.
>>
>> Since I can't determine the problem there isn't anything I can suggest.
>> If you can reproduce the problem in an OSG example that you can share then
>> there is chance then that others can pitch in and see if they can spot the
>> cause of the problem and what to do about it.
>>
>> Robert.
>>
>> On 18 November 2015 at 17:46, Riccardo Corsi <riccardo.corsi at kairos3d.it>
>> wrote:
>>
>>> Hi Robert,
>>>
>>> with "flickering" I mean that the labels of my custom stats lines are
>>> always showing,
>>> while the numeric value besides them disappear in some frames.
>>> They apparently disappear under the conditions explained in my previous
>>> email.
>>> This is true only for my custom stats, and not the default one updated
>>> by osg.
>>> (with vsync disabled things improve, but sometimes the issue is still
>>> visible).
>>>
>>> I might try to reproduce the issue with a heavy enough osg model loaded
>>> in the osguserstats example.
>>>
>>> As for the draw, disabling the vsync dramatically reduces the draw time
>>> shown in the stats.
>>> Should I live with this blocking behavior when vsync is on?
>>> The only drawback is a "fake" (and misleading) stats or there are real
>>> performance penalties?
>>>
>>> Thanks,
>>> Ricky
>>>
>>> On Wed, Nov 18, 2015 at 6:28 PM, Robert Osfield <
>>> robert.osfield at gmail.com> wrote:
>>>
>>>> Hi Ricky,
>>>>
>>>> When you mean flickering, could it simply be that the frame timing
>>>> stats is jumping between two extremes on alternate frames.
>>>>
>>>> In certain circumstances the driver can block and draw dispatch times
>>>> can suddenly go up massively even though that actual system shouldn't be
>>>> overloaded.  In the example you show this is happening. It could possibly
>>>> be something else on the OSG side that is blocking.
>>>>
>>>> As a sanity test try disabling vsync as this can change the behaviour
>>>> of the driver w.r.t blocking.
>>>>
>>>> Robert.
>>>>
>>>> On 18 November 2015 at 16:20, Riccardo Corsi <
>>>> riccardo.corsi at kairos3d.it> wrote:
>>>>
>>>>> Hi Robert,
>>>>>
>>>>> yes for the flickering I refer to the stats on screen.
>>>>>
>>>>> Here's what I've noticed:
>>>>> - I place my stats update between event and update traversal
>>>>> - the flickering appears when I use threading models other than
>>>>> singleThreaded (typically the default DrawThreadPerContext one)
>>>>> AND the cull+draw time hits the frame duration time (around 16ms at
>>>>> 60Hz).
>>>>>
>>>>> Like if the onscreen stats were "dropping" when the application
>>>>> doesn't keep 60Hz.
>>>>> I don't tweak the render code in any way, just a regular osg loop with
>>>>> some custom code in between osg calls.
>>>>>
>>>>>
>>>>> Side note:
>>>>> the draw time shown in the stats almost always fills up the frame time
>>>>> when using threading scheme other than SingleThreaded,
>>>>> even if the drawing thread has little to do.
>>>>> SingleThreaded scheme does not suffer the same issue (see attached
>>>>> screenshot, simple osgviewer).
>>>>> I presume this is due to OS + driver combination,
>>>>> I'm on Win7 64bits + nVidia 970 GTX.
>>>>>
>>>>> Thank you,
>>>>> Ricky
>>>>>
>>>>>
>>>>> On Wed, Nov 18, 2015 at 4:46 PM, Robert Osfield <
>>>>> robert.osfield at gmail.com> wrote:
>>>>>
>>>>>> On 18 November 2015 at 15:14, Riccardo Corsi <
>>>>>> riccardo.corsi at kairos3d.it> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> in my project I'm using some custom statistics as in the
>>>>>>> osguserstats.cpp example.
>>>>>>>
>>>>>>> In the example, user stats are updated every frame between advance()
>>>>>>> and eventTraversal().
>>>>>>>
>>>>>>> In my case, I was trying to update my stats between eventTRaversal()
>>>>>>> and updateTraversal(), where I already execute some other code.
>>>>>>>
>>>>>>> But by doing so, stats do not always show up correctly - sometimes
>>>>>>> they "flicker" and do not show.
>>>>>>> Is the one used in the example the only one safe place to update
>>>>>>> user stats?
>>>>>>>
>>>>>>
>>>>>> The osg::Stats object that is used for recording stats uses a mutex
>>>>>> internally to make sure that setting and getting stats is thread safe.
>>>>>> osg::Stats itself is just a container object though it doesn't do any
>>>>>> rendering so itself can't "flicker".
>>>>>>
>>>>>> When you say flicker I presume we are talking about onscreen stats.
>>>>>> I haven't seen reports of them flickering before.  Perhaps your usage model
>>>>>> trips up the rendering code in some way.  What threading model are you
>>>>>> running the viewer with?  Can you modify an OSG example to reproduce the
>>>>>> issue?
>>>>>>
>>>>>> Robert.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> osg-users mailing list
>>>>>> osg-users at lists.openscenegraph.org
>>>>>>
>>>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> osg-users mailing list
>>>>> osg-users at lists.openscenegraph.org
>>>>>
>>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> osg-users mailing list
>>>> osg-users at lists.openscenegraph.org
>>>>
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> osg-users mailing list
>>> osg-users at lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>>
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
> _______________________________________________
> 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/20151119/76423359/attachment-0003.htm>


More information about the osg-users mailing list