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.osfi...@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.co...@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.osfi...@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.co...@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.osfi...@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.co...@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.osfi...@gmail.com> wrote: >>>>>> >>>>>>> On 18 November 2015 at 15:14, Riccardo Corsi < >>>>>>> riccardo.co...@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@lists.openscenegraph.org >>>>>>> >>>>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> osg-users mailing list >>>>>> osg-users@lists.openscenegraph.org >>>>>> >>>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> osg-users mailing list >>>>> osg-users@lists.openscenegraph.org >>>>> >>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> osg-users mailing list >>>> osg-users@lists.openscenegraph.org >>>> >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>> >>>> >>> >>> _______________________________________________ >>> osg-users mailing list >>> osg-users@lists.openscenegraph.org >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >>> >> >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org