Subject: Timings for the Mars terrain renderer

From: Animesh Chatterjee <[email-masked]>
Date: Tue, 21 Feb 1995 18:57:12 -0500 (EST)

Feb 21, 1995

The following is a description of the current status of an effort to integrate the JPL
terrain rendering software into the Living Textbook project. 

The rendering software has been tested and capability demonstrated in the
following configuration:

1) Spaceflyer - The JPL front end viewer for the SGI, running on a SGI.
2) Router - The JPL networking software to interface the Spaceflyer with 
            the renderer running on the viewer front end.
3) Gateway - The process running on one node of the parallel engine (the SP2) that
             reads viewpoints from the router. The software was developed to implement
             it under the MPI environment and communicate with the router and 
             displayer.
4) Renderer - The Ray Identification parallel rendering software developed at JPL.
              This code was further developed to run MPI to ensure portability across
              platforms and implemented on the SP2 (Performance comparison with 
              the Intel Paragon given below)
5) Networker - A suite of networking modules developed using Berkley sockets
               for 24-bit image transmission from the Gateway node to the Displayer.
6) Displayer - A Tcl/Tk displayer running on a front end for displaying the rendered
               image.

A comparison of timings between runs made on the Intel Paragon and the SP2 is given
below:

Architecture                #nodes             Overall rendering time (seconds/frame)
------------                ------             ----------------------

Intel Paragon                32                           1.710
SP2                          8                            2.020

These results were obtained using a subset of the mars dataset, the timings
were averaged over 181 frames. The time represents the total time from the beginning
of reading in the viewpointst to the time to write out the image. The performance
obtained from the 8-node SP2 implementation agrees well with the anticipated 4 times
speedup per node expected from the SP2 nodes. In future work timings will be
obtained and optimization performed for the various functions - rendering, merging 
data across the nodes and network data transmission. Comparison will also be performed
measure speedup as a function of number of rendering nodes.

A sequential version of the above rendering code has also been developed for
benchmarking purposes. Two versions of the parallel software have been developed - 
(a) one which reads in a pre-recorded fly-path from a file and writes the image either
to a file for later display on a video or writes to the network to be displayed on the
Displayer UI and (b)the second version which reads in the viewpoints interactively 
from the viewer and writes the rendered image to the network to be displayed 
interactively on the Displayer. Both version have been tested and debugged and 
demonstrated.

The following is an outline of the future work (both immediate and long term) I would 
like to perform to continue with the development efforts under the parallel terrain 
rendering thrust:

1) Get detailed timing results for the various components of the software. 
   Investigate performance enhancement mechanisms for the rendering and networking 
   components(ATM over a FDDI switch, data compression). Will use the nodes on the SP2 at 
   Cornell (should get better timings for MPL implementaion of MPI).
2) Archive all software components with a README file with usage guidelines.
3) Create separate networking modules and put all networking code there. This is in
   continuation of my effort to develop the software in a modular fashion for easy
   replacement of modules.
4) Integrate the various functional modules to be started with a single UI(shall 
   use either Tcl or GL for the UI for later porting to Mac's). Will develop it under
   a concurrent server-client model.
5) Develop a concurrent server for the Renderer running at a well known address for  
   the UI clients to connect to for rendering service. The server shall spawn the
   rendering processes.
6) Network the UI to run on a Mac.
7) Data compression for enhanced tranmission rates. Use the ATM protocol.
8) Develop a multimedia UI for the renderer.

With the current status of my efforts the requirements specified (see attached mail)
have been met.

Sincerely,

Animesh