[osg-users] OSG thread profiling results are in!!
James Killian
James_Killian at hotmail.com
Thu Jul 3 07:28:51 PDT 2008
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
>
More information about the osg-users
mailing list