POV-Ray : Documentation : 1.4.3.2 Can POV-Ray use multiple processors?
  POV-Ray 3.6 Documentation Online View  
1.4.3.1 How do I turn animation on?   1.4.3.3 Can I get a wireframe render of my scene?

1.4.3.2 Can POV-Ray use multiple processors?

Short answer: The only way to run POV-Ray on multiple processors is to run several copies of POV-Ray.

Long answer:

Making a program use multiple threads is not as trivial as it may sound. Here are some reasons why it is quite difficult to make with POV-Ray:

  • You cannot do it with standard C (nor C++), and POV-Ray is intended to be very portable. This is not just an issue of philosophy or purism, POV-Ray is really used on a large variety of different platforms.
  • Multithreading is a very complex issue and it is much more difficult to make a bugless multithreaded program than a single-threaded (there are several things in multithreading, like mutual exclusion problems, which make the multithreaded program very non-deterministic). It is not impossible, though, since it has been done (there are patched versions of POV-Ray with multithreading support). However, it is far from trivial.
  • Raytracing is usually thought as an easily threaded problem. You just calculate one pixel and draw it on screen, independent of the other pixels. However, with advanced techniques, like antialiasing and specially stochastic global illumination calculation (referred as "radiosity" in POV-Ray's documentation and syntax) this is not true anymore.
    • To speed up antialiasing, a threshold value is used between pixels. If the difference in color between two pixels is higher than the threshold, then antialiasing is calculated. Of course we need info from the nearby pixels for this.
    • In global illumination calculations lighting values are stored in a spatial tree structure. The following pixels may use the information stored in this tree for their illumination. This means that the pixel calculation at the upper left corner may affect on the color of the pixel in the lower right corner. This is the reason why calculating a radiosity image in parts does not work very well.
    Both problems can probably be solved in some way, but as said, it is far from trivial.

An excellent article about the issue can be found on the Ray Tracing News web page.

Here is an answer from John M. Dlugosz with useful tips:

The POV-Ray rendering engine is a single thread of execution, so when run on a dual Pentium Pro (running NT4) the CPU indicator only goes up to about 50%. POV does not use more than half the available power on the machine.

That is the basic issue, though to quibble a bit it is not exactly true: the rendering engine soaks up one whole CPU, but the editor runs on its own thread, and operating system functions (writing to the file, updating the display, network activity, system background tasks) run on different threads. This gives a little bit of a bonus, and the system uses as much as 54% of available MIPS when watching it. More importantly, the machine is still highly responsive, and editing or other applications continue on without being sluggish.

But for a long render, it is annoying to have one CPU be mostly idle. What can be done to cut rendering time in half (from 20 hours down to 10, for example)?

The simplest thing is to run two copies of POV on the machine. Have one copy render the top half, and the other render the bottom half. Then paste the halves together in your picture editor.

One thing to watch out for: do not just fire up two copies and point them at the same INI file and image file. They will overwrite each other's output and make a big mess. Instead, you must make sure each is writing to a different file.

For moderate renders, you might let one copy chug away on the long render, and use a second copy interactivly to continue development in POV.

1.4.3.1 How do I turn animation on?   1.4.3.3 Can I get a wireframe render of my scene?


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