[osg-users] OSG thread profiling results are in!!

[James Killian]

Gahhh... thanks for the heads up... @#$#@ Microsoft...  I've disabled html
and going to use plain text from now on.

----- Original Message ----- 
From: "Paul Speed" <pspeed at progeeks.com>
To: "OpenSceneGraph Users" <osg-users at lists.openscenegraph.org>
Sent: Thursday, July 03, 2008 3:54 AM
Subject: Re: [osg-users] OSG thread profiling results are in!!


> You are sending in code again. ;)
> -Paul
>
> James Killian wrote:
> >
> > "
> > We are using some particle effects pretty heavily, and we noticed (using
> > filemon) that the smoke image file is being read over and over again,
> > many times (perhaps once per frame).  Is this possible?  We are going to
> > look into that next.  Maybe we can cache the single image (state set)?
> > "
> >
> > I found a way to cache the images.  The Registry in osgDB has the
> > ability to set options.  It appears that _options is NULL by default,
> > the options have a CACHE_IMAGES flag to use along with others.  This
> > works against any code that uses readImage(filename).  There are others
> > to explore too:
> >
> > Does anyone have any experience with using these options?  is there any
> > others that should or should not be used?
> >
> >
> >
> > James Killian
> >
> >     ----- Original Message -----
> >     *From:* rpingry at gmail.com <mailto:rpingry at gmail.com>
> >     *To:* OpenSceneGraph Users
<mailto:osg-users at lists.openscenegraph.org>
> >     *Sent:* Wednesday, July 02, 2008 2:11 PM
> >     *Subject:* Re: [osg-users] OSG thread profiling results are in!!
> >
> >     Hi Robert,
> >
> >     I got the stats handler working on our scene and displaying.  I am
> >     not sure I understand what the different numbers mean and how I
> >     might work with them.  I can see the optimization effort is a big
> >     deal.  I know it is beyond the scope of this group.  Are there any
> >     resources out there to look at?
> >
> >     I have finished the work you had already mentioned, like using png
> >     rather than bmp everywhere.  We are also working on making sure our
> >     images are as small as possible.  We are also going to work on using
> >     LOD.  Since we are in space and most ships are far away, we are sure
> >     we can make a big jump there.  I used osgUtil::Optimizer and that
> >     game me a few more frames.
> >
> >     What are some other suggestions?
> >
> >     We are using some particle effects pretty heavily, and we noticed
> >     (using filemon) that the smoke image file is being read over and
> >     over again, many times (perhaps once per frame).  Is this possible?
> >     We are going to look into that next.  Maybe we can cache the single
> >     image (state set)?
> >
> >     Thanks
> >     -- Rick
> >
> >     On Sat, Jun 28, 2008 at 11:55 AM, Robert Osfield
> >     <robert.osfield at gmail.com <mailto:robert.osfield at gmail.com>> wrote:
> >
> >         On Sat, Jun 28, 2008 at 4:35 PM, James Killian
> >         <James_Killian at hotmail.com <mailto:James_Killian at hotmail.com>>
> >         wrote:
> >          > The thread profiler does provide detailed information of
> >         every threaded
> >          > activity at any given time.  I just wish there was some way
> >         to present the
> >          > information given that would be more meaningful to the group.
> >          >
> >          > What would be great is to have a big balanced scene that can
> >         put OSG Viewer
> >          > to the test in a way where it puts equal intense stress on
> >         update, culling,
> >          > and draw dispatch.  What I'd hope to see is the draw dispatch
> >         be on a
> >          > separate thread, where that thread showed mostly I/O
> >         activity, and the cpu
> >          > activity on other threads.
> >
> >         The osgViewer::StatsHandler will display update, event, cull,
draw
> >         dispatch on all systems and draw GPU stats.  The GPU stats
> >         require an
> >         OpenGL extension that I've only seen Nvidia implement so far, so
you
> >         won't see this stats printed out on all systems.
> >
> >         Also record a camera path/game sequence that you can use for
> >         benchmarking so that every run the app does the same thing, then
> >         you'll be able to study the effects that changes you make have
on
> >         final performance.  You'll also be able to study the above stats
to
> >         where the problems occur in your scene.
> >
> >         As a small note, the OSG in CullDrawThreadPerContext,
> >         DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext
run
> >         graphics in a separate thread.
> >
> >         Robert.
> >         _______________________________________________
> >         osg-users mailing list
> >         osg-users at lists.openscenegraph.org
> >         <mailto:osg-users at lists.openscenegraph.org>
> >
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> >
> >
> >
> >     -- 
> >      >> Rick
> >     Check us out at http://fringe-online.com/
> >
>
  ------------------------------------------------------------------------
> >
> >     _______________________________________________
> >     osg-users mailing list
> >     osg-users at lists.openscenegraph.org
> >
http://lists.openscenegraphorg/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
>