[osg-users] user stats update

[Riccardo Corsi]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20151119/bbd492f1/attachment-0003.htm>