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
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
