[Radiance-general] Instances

[Lucio Boscolo]

Greg, Jack,

Thanks for your explanations, I think I've got it now!

So the RAM memory I can save via -PP is the one taken by the oct.

(hope I haven't misunderstood it again!)

Thanks again! You are great!

Lucio Boscolo Mezzopan
Assistant Designer  |  Lighting
       
Arup
13 Fitzroy Street  London W1T 4BQ  United Kingdom
t +44 20 7636 1531  d +44 20 7755 6311
f +44 20 7755 9012 
www.arup.com

-----Original Message-----
From: Greg Ward [mailto:gregoryjward at gmail.com] 
Sent: 10 January 2011 16:47
To: Radiance general discussion
Subject: Re: [Radiance-general] Instances

Hi Jack,

Your description of the behavior of rpict and rtrace with the -PP option is correct, and you essentially captured the reason behind the lack of memory sharing of ambient values.  Doing so would require locking and coordination of memory sharing across processes, which is implemented a little differently on different systems.  I chose to avoid the differences by taking advantage of the "copy-on-write" behavior of most Unix systems when fork() is called.

When you use the -PP option, rpict (or rtrace) loads in the octree and all the associated, static data structures needed for rendering.  It also loads in any indirect irradiance values that have been previously computed and cached in the ambient file.  Once that is done, it calls fork() to make a copy of the process and waits for additional connections by other rpict/rtrace commands using the same -PP syncfile.  It's a bit awkward, but it works on all modern Unix systems, and requires no further communication among processes once started.

The newer -n option in rvu works similarly, but through a different mechanism.  Rather than making multiple copies of the same process that expects input from stdin to tell it what to do, it has a single parent process that communicates via pipes to all its children, which perform the actual ray tracing.  It still uses the copy-on-write trick, loading the scene and ambient data prior to forking the child processes, but the whole thing is hidden from the user.

I subsequently implemented the -n option in rtrace as well, which is a bit confusing.  In most cases, it's a little more efficient to use rtrace -n than rtrace -PP, and you have to use one or the other.  The times you would still choose rtrace -PP are when you need to start the parallel processes at different times, or take the ray input from different sources.

I don't expect to add a -n option to rpict in the forseeable future.  There are certain things about the way rpict samples the image plane that make such an option problematic, so we're kind of stuck with -PP for now.

Best,
-Greg

> From: Jack de Valpine <jedev at visarc.com>
> Date: January 10, 2011 7:44:50 AM PST
> 
> Hi Lucio,
> 
> This is somewhat confusing. -PP enables multiple process on the same machine to share memory. What is shared is memory space taken up by the octree. Ambient values are shared via the ambient file (-af), so they are not shared in RAM between processes (eg there is not a message passing mechanism for communicating back and forth between processes). At given points processes will write out the ambient data that has been calculated (by the given process) and held in memory to the ambient file. As processes do this they also read in the ambient values from the file (hope I get this right), so this is the method of sharing ambient terms.
> 
> -Jack

_______________________________________________
Radiance-general mailing list
Radiance-general at radiance-online.org
http://www.radiance-online.org/mailman/listinfo/radiance-general
____________________________________________________________
Electronic mail messages entering and leaving Arup  business
systems are scanned for acceptability of content and viruses