From: John Kelso (kelso++at++nist.gov)
Date: 01/09/2006 14:21:22
Many thanks for your detailed reply.
Were you using OSG in an immersive environment (one or more head tracked
stereo screens) by any chance? If so, did you use any package to
facilitate this? And if so, do you mind saying which one, and your
experience with it? Or, did you create your own?
-John
On Mon, 9 Jan 2006, Rick van Haasen wrote:
> 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.
>
This archive was generated by hypermail 2b29 : Mon Jan 09 2006 - 14:21:32 PST