Jim Helman (jimh++at++surreal)
Tue, 30 Nov 93 15:33:06 -0800
Driving 3 graphics pipes and 8 channels with 2 CPUs is very aggressive.
I doubt you will achieve 30Hz. A configuration for maximum throughput
would have 2 CPUs per hardware graphics pipe (CULL+DRAW) plus one for the
APP plus one for Unix. If your many moving models all need 30Hz terrain
following, you may need more (MP intersections are supported in 1.2).
Under 1.2, you can get by with 1 CPU per graphics pipe at some cost in
throughput by using a cull traversal which directly draws, but under
1.1 your cull time will subtract from your drawing time.
> Attempts to extend to multiple pipelines meet with limited success.
> When the scene is restricted to a single pfGeode cube (no .flt files
> loaded), we get high (~75%) utilization on both processors driving
> one channel on each of the 3 pipes at 20Hz (using PFMP_APPCULLDRAW
> or PFMP_APP_CULL_DRAW -- PFMP_APPCULL_DRAW is illegal).
>
Both PFMP_APPCULLDRAW, PFMP_APPCULL_DRAW should work as arguments to
pfMultipipe. But in multipipe mode Performer will go ahead and fork
the CULL leaving PFMP_APP_CULLDRAW, PFMP_APP_CULL_DRAW, respectively.
> Things really go downhill when the scene is loaded from a flight
> file. There are frequent bus errors and segmentation faults. Typical
> Performer diagnostics are (I paraphrase):
> pfFree() -- attempt to free block not allocated with pfMalloc()
> pfMakeEmptyDList() -- NULL pfDispList
> pfDrawDList() -- NULL pfDispList
>
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:06 PDT