On Feb 16, 2007, at 12:52 AM, Stephan Huber wrote:
E. Wing schrieb:
First, for the Multi-threaded OpenGL engine, you should only activate
it when you have multiple processors. (I noticed it has been
commented
out because of performance issues.) If you are on a single processor
machine, you will likely see performance degradation. You should do a
CPU count check at runtime and decide if you want to activate it.
This is no longer necessary (it was with the initial seeds, but not
the released version in 10.4.8+). Downstream from the CGLEnable call
we detect whether you have multiple CPU cores and will ignore the
call if there's just one.
(This code is already in the osgsimpleviewerCocoa,) In well written
OpenGL code with multiple processors available, the multithreaded
engine usually shows huge performance benefits. (I know Doom 3 and
World of Warcraft showed huge gains.) My sense is that OSG falls into
the well written OpenGL code camp so turning it on is probably the
thing to do.
Have you seen the discussion of Robert and me about this topic on
osg-submissions?
The Multithreaded OpenGL execution helps only if you are cpu-bound.
If your app is not cpu-bound the overhead of the multithreaded-
execution of opengl-calls costs more performance as you wil gain
with it. (showing the cow in osgviewer with multithreaded opengl-
execution degrades the performance to 45fps on a MacPro
(fregardless of the chosens threading model of osgViewer), most of
the time the processor is waiting on mutexes etc.) The apple-tech-
note notes this also.
I don't follow osg-submissions so I'm curious what the original fps
of the cow in osgviewer was. If you're seeing more than a small %
overhead then I'd like to know more.
Re: only helps if you are CPU bound: This is correct but there is
some subtlety to the topic, remember that the bottleneck typically
moves around a lot during a frame so you might get enough benefit
during a CPU-bound part of a frame to overcome the overhead when
you're xform or fill limited later.
Even more important (and something that helps all OpenGL based apps,
but is especially critical with the multithreaded engine) is to get
rid of sync points like glGet*, glFlush, glFinish etc., and to use
the extensions (FBO, PBO etc) that allow the corresponding pixel &
framebuffer ops to run asynchronously (ie compared to plain
glReadPixels or using pbuffers for render-to-texture, etc).
Extraneous calls to glGet*/etc are pretty rare in the tuned core of a
scene graph but it's something people add themselves in subclasses /
callbacks / elsewhere in their apps all too often.
Allan
___________
Allan Schaffer
2D & 3D Graphics Evangelist
[EMAIL PROTECTED]
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
