[osg-users] user stats update

Fri Nov 20 10:04:20 PST 2015

Hi Robert,

I clearly understand.
Can you please just shade some light on the other question that came up in
the conversation?

> 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?

Thank you!
Ricky

On Thu, Nov 19, 2015 at 4:20 PM, Robert Osfield <robert.osfield at gmail.com>
wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20151120/57a9bc27/attachment-0003.htm>