From: Rick van Haasen (rick.van.haasen++at++philips.com)
Date: 01/09/2006 07:07:24
I have used both OSG and Performer on Onyx3400 (2-pipe IR4) and PC
(Linux witn 2x Nvidia FX1400).
my conclusion (until now) is as follows:
-on Linux PC systems, using few CPU's and few graphic cards
both Performer and OSG perform well. On Windows PC's OSG could
run better because of multi-hreading (Performer doesn't support
multi-processing on Windows).
-on larger systems with many CPU's and graphic pipes (like SGI Onyx),
Performer seems to do a better job.
an architectural difference is the way multi-processing/multi-threading is
done:
Performer can use a pipeline that enables parallel processing of the app
cull
and draw stages, at the cost of max. 3 frames delay.
while(1) {
pfFrame();
}
OSG doesn't use a pipeline, but does everything within 1 frame period.
while(1) {
// Do the app stuff
app();
osgframe();
}
calling osgFrame() will trigger both the cull and draw threads.
I have not looked how it is implemented but my guess is
that it compares to what is called the DrawOverlappedCull mode in
Performer,
where a producer/consumer method is used to transfer the cull results to
the draw thread. In that case, after being triggered, the draw thread has
to wait for data being produced by the cull thread, which (at least in
principle)
is less efficient than the pipeline aproach.
For OSG, the app() processing could also be done parallel to osgframe()
by using a double buffer scheme, were one (or more threads) calculate data
to be processed by osgframe() during the next iteration.
Performer has the pfFlux object for this purpose.
Performer further scales by using a set of (cull&draw) processes for each
pipe.
OSG uses a set of (cul&draw) threads for each camera.
If you use for example (as in my case) 2 camera's per pipe, OSG will
spawn
more threads than i would like: each pipe can only be used by 1 draw
process/thread
at a time, so its better to let 1 process/thread sequentially process all
camera's
that are "mapped" to a pipe.
Don Burns (OSG) mentioned a multiprocess/ multithread issue that has to do
with
the location of memory on Prisms (and probably to all shared memory SGI
systems).
The process aproach used by Performer will physicaly locate the memory
more efficient than the thread aproach of OSG (more close tho the CPU that
executes
the process in a CPU locked system). This is more a "category of 10%
performance"
issue. Ask Don if you want to know more about this.
A last issue is the opensource aspect of OSG. This is a big advantage of
OSG,
which results in an increasing number of plugins being developed,tested
and debugged
by the community.
Rick.
"Dorosky, Christopher G" <christopher.g.dorosky++at++lmco.com>
Sent by:
owner-info-performer++at++performer.engr.sgi.com
2006-01-04 21:32
To
Steve Satterfield <steve++at++nist.gov>
Performer Mailing List <info-performer++at++sgi.com>
cc
John Kelso <kelso++at++nist.gov>
Subject
RE: [info-performer] Performer vs OpensScenegraph
Classification
I've used both.
Here is the least controversial answer that I can give.
Performer is closed source.
OpenSceneGraph is open source.
Performer has a longer history than OSG.
Since Performer is closed source, they have dedicated some extra effort
into the "helper" functions that do some complex tasks for you, because
some of them would require in depth source knowledge to accomplish
efficiently.
OSG seems to lack some of this, but it is relatively young. At the same
time, the C++ architechture of OSG is by far more robust than
Performer's, although it's virtual class model isn't too shabby either.
Performer seems to be more for someone who wants a rich set of
functionality that already works, even if it isn't the most efficient
example, whereas OSG is for people that want infinite expandability, and
the power to change and understand all aspects of their program.
Kinda like Performer = automatic transmission
OSG = manual.
Don't forget, Performer has a per-machine license, while OSG is free.
Can't give you performance numbers, I never had a fair side by side
test.
Chris
-----Original Message-----
From: owner-info-performer++at++performer.engr.sgi.com
[mailto:owner-info-performer++at++performer.engr.sgi.com] On Behalf Of Steve
Satterfield
Sent: Wednesday, January 04, 2006 1:31 PM
To: Performer Mailing List
Cc: Steve Satterfield; John Kelso
Subject: [info-performer] Performer vs OpensScenegraph
Has anyone done any comparisons between Performer and OpenScensGraph
(http://www.openscenegraph.org/)?
Our management is beginning to hear about OSG and expressing some
interest in switching.
I am assuming that Performer would run the best on the Prism
architecture, but it would be good to hear some hard facts or
experiences
OSG is getting a lot of publicity and a growing following.
What are your reasons for staying with Performer?
What is the relative relative performance?
What about in a multi-pipe/immersive environment?
Thanks,
Steve
-----------------------------------------------------------------------
List Archives, Info, FAQ: http://www.sgi.com/software/performer/
Open Development Project: http://oss.sgi.com/projects/performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
-----------------------------------------------------------------------
-----------------------------------------------------------------------
List Archives, Info, FAQ: http://www.sgi.com/software/performer/
Open Development Project: http://oss.sgi.com/projects/performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
-----------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Mon Jan 09 2006 - 07:09:04 PST