Dear Paul, (and others)

This is what I've found out so far about the SGI's....

o Indys (Galilieo-atm and Brahe-atm)
  These are relatively low-end SGI workstations with R4000
	 100MHz processors in them and 32 Mbytes of memory.
  They have 24 bit color buffers for graphics, however I don't
  think that they have all the graphics hardware that SGI is famous
  for. They have the OpenGL graphics library, but I believe it may
  be implemented in software instead of hardware. 
  These are the stats....
	26K triangles per second
	1.4M 10-Pixel X11 lines per second

o OpenGL
  This is the graphics library currently supported by SGI for easily writing
  3d graphics programs. There are a couple of higher level Application 
  Programming Interfaces written on top of them for application devlopment
  such as IRIS Inventor, and IRIS Explorer.
  This library is meant to be machine specific (hence "OpenGL") and supports
  a wide variety of functions no matter what the hardware. 

  Benefits: According to its own propaganda.... it sounds like its going to 
  be the next standard. It's endorsed by Microsoft and Intel (included 
  in Windows NT) for what that's worth. 

  Downfall: As far as NPAC goes, it's onlt supported by the SGI machines,
  so if we wanted to use it we would have to use them. 

o Challenge
  Right now the Challenge is a network server for NPAC. I'm not exactly sure
  what this means, especially in terms of load and performance for other 
  applications. (Do ya'll?) But as such, it has no graphics hooked up to it
  and would propbably have to use one of the indy's for display. What it does
  have is 2 150 MHz R4400 processors. However, it lacks the software to use 
  these together in an application and now only uses them for load balancing. 
  What it needs is power C, a part of its C compiler that will automatically 
  parallelize C code written for it. It does have shared memory so that it 
  would be possible to write a simple message passing library for it. (Alvin's
  idea...)

  
Options (or what I think we should do)
 
I think we have 2 choices (which are the same 2 choices we've had all along)

1. Write a renderer with openGL or something for the Challenge, either
   aquire Power C or try to write a message passing interface for it to 
   speed things up.

2. (Probably the one with the most speed up)
   Do everything on the DEC alpha farm or the CM-5 (these are both 
   connected to the indy's by atm right?) and ship the raster image over.
   This is the approach favored in the Herken, Hodicke, and Schmidt paper
   (High Image Quality, Interactive Rendering on Scalable Parallel Systems)
   and they seem to think that it is the only way to do it. Perhaps we can
   use some of their structure when designing our project


Well, if I'm off base, tell me. If there is anything I should be looking at,
tell me. But I'd like to get started on something specific real soon (like
programming.)


Cheers,
Stephanie