[Radiance-general] Re: multiprocessor systems, Radiance, and you

[Greg Ward]

I'm a little confused as to which list to reply to on this subject, as 
things have been sent to both lists.  So, I'll send my reply to both 
places...

I have been working on an ANSI-C version of Radiance, which is mostly 
ready at this point.  The library files in src/common and the rendering 
code in src/rt now uses prototypes for all its functions, and I have 
collected the rendering code into a new library that may be linked to 
other applications.  I have also added an interface to this library 
that provides sequential and parallel (multiprocessor -- not 
distributed) ray-tracing.  Using this interface, I have developed a new 
animation program, called "ranimove", which in a single process 
performs object and camera animation with image-based rendering 
(similar to pinterp but without interpolating frames) and optimized, 
progressive rendering of animations with task focus.  All rendering, 
filtering, etc. is handled in a single process.  Only xform and oconv 
are executed to update the scene octree at each frame.

That's mostly an aside, but I wanted to mention it as background for 
what I'm about to say on ambient value sharing.  The code in rholo 
works similarly to the code in rpiece and ranimate, which use separate 
invocations of rtrace or rpict to do their ray calculations.  The code 
in the new ranimove program is different in the sense that the 
rendering happens in the same process (or identical children of the 
same process), but ambient value sharing is the same.

The main issue I have with using Samba or MPI or PVM or whatever you 
want to use is the difficulty of requiring or including a third-party 
library with Radiance.  If you require that the user have this software 
in order to install Radiance on their platform, that can be an 
insurmountable burden for some people, and an inconvenience at the very 
least for others.  If you include the library with Radiance, then you 
invite at least three problems:

	1) The user may already have a version of the same library.
	2) The library may be updated asynchronously by its author, causing 
incompatibilities.
	3) The library may not be portable to all the systems Radiance is.

For this reason, I have only made rare exceptions to the "no library 
dependencies" rule in Radiance.  One is for TIFF import/export, where I 
have the very well-established and stable TIFF library by Sam Leffler 
to rely on.  Another is X11, which is almost ubiquitous on Unix.  The 
third is for OpenGL, which is supported on most platforms, and may be 
excluded from compilation without too much difficulty.  I do not 
include an OpenGL library with Radiance.

If we want to share ambient values without using the NFS lock manager, 
we either have to employ some third-party library (Samba, MPI, PVM, 
EIEIO, whatever), or we need to find a way to do it that is universally 
supported on Unix.

Unfortunately, the only universally supported interprocess 
communication call for Unix (as far as I know) is the socketpair(2) 
call.  This is just about as nasty as any system call I've ever 
encountered, which is why I've avoided it.  It requires all sorts of 
knowledge about the network to link up with another process somewhere, 
and I've never been able to fathom the intracacies to making it work.  
(If anyone has some simple example code, please share it with me.)  
Also, there is no hope of porting this to Windows.

This brings us back to my original question when this thread was 
started sometime last Spring (I think) -- is there a stable, portable 
library for sharing process data across the network.  I thought the 
consensus was that Samba was the best.  Can it be distributed and 
compiled, or is it readily available for all platforms?  How much of a 
burden is it to users to install this along with Radiance?  Should we 
offer it only as an option for people who want to do parallel rendering 
on platforms with unreliable NFS lock managers, or should we make it a 
requirement for everyone on every platform?

-Greg