POV-Ray : Newsgroups : povray.unix : Testing distributed rendering script : Re: Testing distributed rendering script Server Time
28 Jul 2024 16:20:27 EDT (-0400)
  Re: Testing distributed rendering script  
From: Yann Ramin
Date: 20 Jul 2000 13:44:34
Message: <39773A96.E3D097D3@atrustrivalie.eu.org>
Whats wrong with using an MPI version of POV-Ray?  It has much better
load balancing abilities, handles animations, etc.  I first used a
tweaked version of the PVM patch for 3.1e (it applied somewhat to 3.1g),
but then went to the MPI version. Sure, MPI is not small (7mb source
tarball), but it works, and uses rsh :)

Yann

Warp wrote:
> 
>   I have said several times, that "it should be quite easy to make a shell
> script that automates the process of distributing the rendering to several
> computers".
>   Well, I decided to try, not only to see how easy it is, but of course also
> because it's very useful.
>   Here at school I have access to many UltraSparc computers that I can use
> for the purpose. Specially the fact that I can rsh (or ssh) to any other
> computer here at work and that every one sees the same file system makes it
> easy.
>   I first tried thinking how to achieve the following method (which should be
> the best): For each process take the next unrendered image block and render
> it until there are no more free blocks.
>   The problem here is communication and mutual exclusion (two of the basic
> problems in multithreading). How to get the next free block? How to avoid
> two processes rendering the same block? It's harder than one could think,
> specially when you only have the hard disk to communicate between processes
> (I didn't even think about some network communication system).
>   So I decided to use a much simpler (but more inefficient) method: Each
> process just renders it's own predefined blocks and that's it. So if
> there are two processes, one renders the even blocks and the other
> renders the odd blocks. This, of course, is not as efficient (the render
> is exactly as long as the slowest process), but at least is better than
> nothing and very easy to implement (although the render is as long as the
> slowest process, each process has much less to render than the whole image).
>   Then I had another problem: After the computers have rendered their parts,
> how to join them? After much searching of programs to join image parts, I
> remembered one interesting thing: The raw targa format has 18 bytes of header
> data and then the raw image after that. I got an idea: What if I just copy
> the data after the 18th byte from all the other partial images to the end of
> the first partial image? There's even a handy utility in Unix to make
> this (cut). Well, I tried it and it worked like a marvel. Easy and fast.
> 
>   So I made the script and tried with several block sizes with 8 machines.
> At least with the test scene I used a block size of about 17 lines gave a
> good result.
>   The test image with antialiasing 0.1 takes about 15.5 minutes to render
> with one computer and 2.25 minutes to render with 8 computers. Without
> antialiasing it takes 6 minutes with one computer and 55 seconds with 8.
> 
>   If anyone is interested in the script, I can post it here. It has several
> limitations (for example it's made for zsh), but someone can get good ideas
> from it.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

-- 

--------------------------------------------------------------------
Yann Ramin			atr### [at] atrustrivalieeuorg
Atrus Trivalie Productions	www.redshift.com/~yramin
Monterey High IT		www.montereyhigh.com
ICQ 				46805627
AIM				oddatrus
Marina, CA

IRM Developer                   Network Toaster Developer
SNTS Developer                  KLevel Developer

(yes, this .signature is way too big)

"All cats die.  Socrates is dead.  Therefore Socrates is a cat."
	- The Logician

		THE STORY OF CREATION

In the beginning there was data.  The data was without form and null,
and darkness was upon the face of the console; and the Spirit of IBM
was moving over the face of the market.  And DEC said, "Let there be
registers"; and there were registers.  And DEC saw that they carried;
and DEC seperated the data from the instructions.  DEC called the data
Stack, and the instructions they called Code.  And there was evening
and there was a maorning, one interrupt...
		-- Rico Tudor

William Safire's Rules for Writers:

Remembe


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.