[Radiance-general] Re: Radiance-general digest, Vol 1 #210 - 2 msgs
Charles Ehrlich
[email protected]
Fri, 17 Jan 2003 12:01:00 -0800 (PST)
--0-1999488573-1042833660=:94858
Content-Type: text/plain; charset=us-ascii
My experience with multi-processor systems and Radiance rendering is that it is best to run two separate images on each process--AFTER the initial ambient file has been sufficiently seeded.
During the seeding of the ambient file, it is efficacious to rendering two different views of the space on each processor using RVIEW. That way, the random sampling of the image plane (rather than the sequential scanline ordering) assures that ambient rays are distributed throughout the space and that Radiance will find the "hot spots" earlier in the ambient file seeding process. Of course, a low-resolution image has a similar effect, but if you are rendering interactively, you can also judge how long it takes to get close and stop the processes when you think it is ready. The random sampling, in my experience, reduces overall error and reduces the chances that the final rendering will have to be thrown away because of large sources of light (error) introduced late in the rendering process.
If you are rendering the same image on both processes using rpiece and the pfork() routine, a peculiar situation arises. Eventually the ambient file becomes very large and later values stored to the file have updated--many times--earlier values in the file. When the two rpict processes are initially begun, they share memory space for the executable part of the code and the static parts of the scene. As the ambient file grows, the part of the ambient file that is resident in RAM becomes larger and larger for each process. Eventually, there seems to arise a significant delay caused by each of these processes having to access each-other's locked memory space for bits of the ambient file. I have noticed significant performance increases when the processes are stopped, and re-started. Importantly, the second process should be started after some delay (depening upon the size of the ambient file)...presumably after rpict has had time to process the ambient file and coalesce similar/nearby values. That way the second process can share more memory with the first process that is no longer going to be changing.
P.S. Anyone going to the anti-war peace marches in San Francisco or Washington D.C. this Saturday, Jan. 18th? I'll be in the Environmentally friendly eco-car-rally in San Francisco. Look for my green VW Golf TDI running Biodiesel. www.biodezl.com. More info about the demonstrations are available at: http://www.workingassets.com/nowar and www.internationalANSWER.org
-Chas
Charles Ehrlich
Project Manager
Heschong Mahone Group
11626 Fair Oaks Blvd. #302
Fair Oaks, CA 95628
Phone: (916) 962-7001
Fax: (916) 962-0101
http://www.h-m-g.com
--0-1999488573-1042833660=:94858
Content-Type: text/html; charset=us-ascii
<P>
<P>My experience with multi-processor systems and Radiance rendering is that it is best to run two separate images on each process--AFTER the initial ambient file has been sufficiently seeded.
<P>During the seeding of the ambient file, it is efficacious to rendering two different views of the space on each processor using RVIEW. That way, the random sampling of the image plane (rather than the sequential scanline ordering) assures that ambient rays are distributed throughout the space and that Radiance will find the "hot spots" earlier in the ambient file seeding process. Of course, a low-resolution image has a similar effect, but if you are rendering interactively, you can also judge how long it takes to get close and stop the processes when you think it is ready. The random sampling, in my experience, reduces overall error and reduces the chances that the final rendering will have to be thrown away because of large sources of light (error) introduced late in the rendering process.
<P>If you are rendering the same image on both processes using rpiece and the pfork() routine, a peculiar situation arises. Eventually the ambient file becomes very large and later values stored to the file have updated--many times--earlier values in the file. When the two rpict processes are initially begun, they share memory space for the executable part of the code and the static parts of the scene. As the ambient file grows, the part of the ambient file that is resident in RAM becomes larger and larger for each process. Eventually, there seems to arise a significant delay caused by each of these processes having to access each-other's locked memory space for bits of the ambient file. I have noticed significant performance increases when the processes are stopped, and re-started. Importantly, the second process should be started after some delay (depening upon the size of the ambient file)...presumably after rpict has had time to process the ambient file and coalesce similar/nearby values. That way the second process can share more memory with the first process that is no longer going to be changing.
<P>P.S. Anyone going to the anti-war peace marches in San Francisco or Washington D.C. this Saturday, Jan. 18th? I'll be in the Environmentally friendly eco-car-rally in San Francisco. Look for my green VW Golf TDI running Biodiesel. <A href="http://www.biodezl.com">www.biodezl.com</A>. More info about the demonstrations are available at: <A href="http://www.workingassets.com/nowar" target=_blank>http://www.workingassets.com/nowar</A> and <A href="http://www.internationalANSWER.org">www.internationalANSWER.org</A>
<P>-Chas<BR>Charles Ehrlich<BR><FONT size=2><BR>Project Manager<BR>Heschong Mahone Group<BR>11626 Fair Oaks Blvd. #302<BR>Fair Oaks, CA 95628<BR>Phone: (916) 962-7001<BR>Fax: (916) 962-0101<A href="mailto:[email protected]"><BR></A><A href="http://www.h-m-g.com">http://www.h-m-g.com</A></P></FONT>
--0-1999488573-1042833660=:94858--