[osg-users] how to interpret values shown by stats handler
Hi all, I'm trying to optimize the display speed of my application by testing various techniques. In order to do exact measures I implemented a mechanism where I can trigger single frame() calls from my keyboard. Curiously the GPU times shown by the stats handler are always drifting somehow over significant ranges before getting stable. Does anybody know if there is some averaging over a couple of frames or is there any other effect I don't see at the moment? Or is this a kind of caching effect? It's difficult to judge the effects of techniques under those circumstances if I don't have an idea what is causing the drifts. Thanks for any hints. - Werner - ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to interpret values shown by stats handler
Hi Werner, The values are averaged as otherwise they'd jump around so much that they would be un-readable blur. The exact values are all collated in the the various osg::Stats objects, so perhaps you can have a look at these. As a general note, OpenGL timing data is not deterministic, this is partly down to the OpenGL FIFO blocking at different points in the frame, or sometimes the OS and the driver interacting in different ways each frame. This effect gets worse the more overloaded your system is. This means you need to take the stats as hint to what is going on, but it's not hard fast, to really understand you need to be aware of how various things interact. Robert. Robert. On Tue, 17 Jul 2018 at 10:43, Werner Modenbach wrote: > > Hi all, > > I'm trying to optimize the display speed of my application by testing > various techniques. > > In order to do exact measures I implemented a mechanism where I can > trigger single frame() calls from my keyboard. > > Curiously the GPU times shown by the stats handler are always drifting > somehow over significant ranges > before getting stable. Does anybody know if there is some averaging over > a couple of frames or is there any other effect > I don't see at the moment? Or is this a kind of caching effect? > > It's difficult to judge the effects of techniques under those > circumstances if I don't have an idea what is causing the drifts. > > Thanks for any hints. > > - Werner - > > > ___ > 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
Re: [osg-users] how to interpret values shown by stats handler
OK, thanks Robert. So I do a couple of frames until values stabilize. The shown average is what I finally need. - Werner - Am 17.07.2018 um 12:12 schrieb Robert Osfield: > Hi Werner, > > The values are averaged as otherwise they'd jump around so much that > they would be un-readable blur. > > The exact values are all collated in the the various osg::Stats > objects, so perhaps you can have a look at these. > > As a general note, OpenGL timing data is not deterministic, this is > partly down to the OpenGL FIFO blocking at different points in the > frame, or sometimes the OS and the driver interacting in different > ways each frame. This effect gets worse the more overloaded your > system is. > > This means you need to take the stats as hint to what is going on, but > it's not hard fast, to really understand you need to be aware of how > various things interact. > > Robert. > > Robert. > On Tue, 17 Jul 2018 at 10:43, Werner Modenbach > wrote: >> Hi all, >> >> I'm trying to optimize the display speed of my application by testing >> various techniques. >> >> In order to do exact measures I implemented a mechanism where I can >> trigger single frame() calls from my keyboard. >> >> Curiously the GPU times shown by the stats handler are always drifting >> somehow over significant ranges >> before getting stable. Does anybody know if there is some averaging over >> a couple of frames or is there any other effect >> I don't see at the moment? Or is this a kind of caching effect? >> >> It's difficult to judge the effects of techniques under those >> circumstances if I don't have an idea what is causing the drifts. >> >> Thanks for any hints. >> >> - Werner - >> >> >> ___ >> 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
Re: [osg-users] osgQt + OSG 3.6.2 Status
Thanks for the info @davisjamesf. I wish I knew what secret sauce was needed to get this running. I'll keep trying and maybe I'll have luck with some future osgQt release. If you or anyone have some example code for a single view class derived from osgQt::GLWidget and osgViewer (or a better design) that can display a scene using current osgQt + OSG 3.6.2 that should get me started. Thanks, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74354#74354 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
