[osg-users] OSG thread profiling results are in!!
rpingry at gmail.com
rpingry at gmail.com
Wed Jul 2 12:11:15 PDT 2008
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)?
On Sat, Jun 28, 2008 at 11:55 AM, Robert Osfield <robert.osfield at gmail.com>
> On Sat, Jun 28, 2008 at 4:35 PM, James Killian
> <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
> > 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
> > to the test in a way where it puts equal intense stress on update,
> > 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
> > 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.
> osg-users mailing list
> osg-users at lists.openscenegraph.org
Check us out at http://fringe-online.com/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the osg-users