Thanks for the feedback. I'll start with these areas as you suggested and
see what numbers I am getting.
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.
Well anyhow... I got my work cut out for me now... thanks again.
James Killian
----- Original Message -----
From: "Robert Osfield" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" <osg-users@lists.openscenegraph.org>
Sent: Saturday, June 28, 2008 4:22 AM
Subject: Re: [osg-users] OSG thread profiling results are in!!
Hi James,
I've read your emails but I'm afraid the stats mean absolutely nothing
do me. One will really need to be find out what parts of the OSG i.e.
what function calls are the current bottleneck.
As general note, performance optimization with scene graphs as almost
always an issue of improving the balance of the scene graph, be it
update, cull, draw dispatch or draw GPU, it's almost always a poor
scene graph that is at fault. You can often improve performance by
10x and more by simply fixing the scene graph. Doing low level code
optimization will rarely get you anything like the performance
improvement that you'd get by just fixing the scene graph.
Given this, diving into low level profiling could well be a case of
not seeing the wood from the trees. So I'd recommend if you want
your app to go faster start with the basics, are your CPU or GPU
limited. Then are you update, cull or draw dispatch limited? Then
depending upon what results you get consider why the scene graph
itself is making things so slow. This process will typically lead you
to things you can do to your scene graph to fix the performance
bottleneck, and all this without touching the actual code.
Performance optimization is huge topic, but hopefully I'll have given
you a little pointer to priorities I'd apply.
Robert.
On Sat, Jun 28, 2008 at 4:12 AM, James Killian
<[EMAIL PROTECTED]> wrote:
Here are some interesting profile results from the threaded profiler.
First here is the ground work:
OSG SVN 8482 using VS 7.1 with threading enabled (interlocked config).
The
actual client code tested that pushes some stress on osg is our game
which
anyone can download here http://www.fringe-online.com/. So I run this
and
measure the thread performance using Intel's thread compiler. So far,
our
client code main loop is very similar to how it is in the osg viewer (no
fancy optimizations).
There are 2 machines I have tested now... I'll post a copy of a different
message I sent a few days ago here (to keep all info in this thread)
-----------snip----------------
Robert,
This proposal you mention for 2.6 will it help balance the cpu workload
against the gpu I/O bottleneck?
I've been doing some osg performance benchmark research on thread
synchronization using the Intel Threaded compiler, and so far the results
are looking really good except for a 26% over-utilization due to
sleeping. I
do want to say awesome job to those responsible for threading, the amount
of
critical section use looked very good! All the worker threads also had
good
profiling results.
The ultimate test I want to try today deals with an intentional GPU
bottleneck... where I have a quadcore that pipes graphics out a PCI
graphics
card. If anyone is interested I'll post these test results. I know now
that using a quad core there is lack of parallelization (e.g. 25% 85% 15%
15%), but that is a different battle for a different time.
I do want to get to the bottom of the profiling and determine how well
the
workload is balanced against the gpu i/o, and see if there is some
opportunity for optimization here.
-----------------snip------------------------
Today I have the numbers from the souped up machine with a poor poor pci
graphics card. The first thing to note is that the game never exceeded
18%
cpu usage!! When I profiled 65% of the main thread was devoted to
"serial"
time and the bulk of the cpu time was on *this thread* and
PrintSchedulingInfo [20] thread. The thread 20 showed 21% contributed to
blocking, but the rest of it was active. The rest of the threads (like
with
my machine) looked really good! it is just too bad they don't do much
work.
Realistically my machine at work is not typical due to the pci graphics,
but
it did put good stresses to show where the I/O bottle neck is (on the
main
thread). My machine at home is a dual p 2.4 with NVidia GeForce 5900XT.
When testing other games on my home machine I get great frame rate, so my
goal will be to osg's performance to something comparable.
Aside from the threading profiler, I have tested AMD code analyst to find
the most frequent called code, and for osg 1.2 it turned out to be the
Matrix Multiply. Aside from that OSG itself took a significant bulk of
the
CPU workload. This AMD profiler works differently in that it does not
count
sleeping or I/O time, but rather keeps note of the most frequent called.
At
some point I'll retest for code optimizations, but not yet... the real
gain
now is to balance the CPU rendering against it sending to GPU. It would
be
great if I can find a solution that can benefit the whole osg community
(all
platforms).
If anyone has an interest in faster performance using the new osgViewer
please share with me some ideas thanks. I can track where bottlenecks
are,
but working out a good solution will take some time to learn. I'll need
to
profile with VS 9 and OpenMP to see if this helps.
_______________________________________________
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
