JAYDEE++at++zeus.ats.qc.ca
Tue, 30 Nov 1993 16:22:20 EDT-500
The hardware involved is an Onyx RE^2 with three graphics pipelines,
each of which has the Multi-Channel Option installed. Other
relevant tidbits from hinv are:
2 150 MHZ IP19 Processors
CPU: MIPS R4400 Processor Chip Revision: 5.0
FPU: MIPS R4010 Floating Point Chip Revision: 0.0
Main memory size: 128 Mbytes, 2-way interleaved
Multi-Channel Option board installed
RealityEngine Graphics option installed
Multi-Channel Option board installed
RealityEngine Graphics option installed
Multi-Channel Option board installed
RealityEngine Graphics option installed
Our application requires 8 45-degree channels of realistic visuals
with an update rate of 30Hz. The eyepoint is generally fixed, but
there is a potentially large number of visible moving models. The
world and moving model databases are loaded from MultiGen .flt
files.
Currently, we can achieve 20Hz with occasional blips in performance
with 3 channels on a single pipe (the PFMP_APPCULL_DRAW multiprocessing
model seems to give the smoothest performance).
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).
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
These diagnostics appear on the first frame.
When the program does run successfully, there is no texture visible
on the channels for pipes 1 and 2 (pipe 0 is rendered correctly).
Texture does work on all pipes with the trivial cubic pfGeode.
It appears that the .flt loader is unable to deal with multipipe/multi
processing. I have broached the topic with Software Systems (who now
support the loader), but have yet to hear back from them. I have
also opened a service call to SGI directly.
Does anyone out there have experience with a similar hardware/software
configuration? In particular, what needs to be allocated in shared
memory so as to be accessible from the multitude of draw processes
in the multiple pipe scenario? Does the whole scene graph have
to live in the shared arena? It was my impression that everything
allocated in the application process prior to the forking of cull
and draw processes would be visible to the child processes. Of
course, LoadFlt() is called _after_ pfConfig(), which purportedly
perpetrates the forking...
Is there a sample program for multiple pipes? I'm a bit confused
about the callback function for pfInitPipe(). How much needs to be
done on a per pipe basis (e.g. config a gl window), and what is done
only once per application (device queuing, applying default texture
environment...)? Similarly for the channel draw callback function.
Once the application is limping along with no catastrophic errors,
is there an easy way to determine to what extent it is CPU-bound?
Are we asking too much of our 2 processors (it looks like
PFMP_APP_CULL_DRAW results in 7 processes)?
Any feedback or pointers to useful sources of information would
be greatly appreciated.
Cheers,
Jean Daigle.
-----------------------------------------------------------------
| Jean Daigle ATS AeroTechnologies Inc. |
| Software Designer 1250 Boul Marie-Victorin |
| St. Bruno, QC J3V 6B8 |
| jaydee++at++ats.qc.ca Tel: (514) 441-9000 Fax: (514) 441-6789 |
-----------------------------------------------------------------
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:06 PDT