View Full Version : understanding threads/threading

11-03-2003, 04:54 PM
I've played with threading based on some comments I've read, but from my viewpoint, selecting 2, 4, 8, etc. threads seems to be a sort of experimental, hit-or-miss thing.

Can anyone share wisdom as to how to arrive at the correct number of threads for a still render or animation sequence?

Is it a safe assumption that if a given threads number is faster for a small (ie 320x240) test render, it will be faster for a larger still? Maybe not so for animation as what the camera sees will change with time?

thanks for any insight.


11-03-2003, 05:42 PM
I'm not sure of the exact science behind multi-threading, but I do test renders at 1, 2, 4, and 8 just to make sure there is no huge savings in render time. I do this before rendering on one machine. Normally, I use a render farm. In that case multi-threading is not used because each render node processor gets one frame of animation to render. Only when you work on one machine (a dual processor for example) is multi-threading noticeable.
Also, setting the Segment Memory Limit so that your scene renders in one pass can save lots of render time. Although, I've had scenes with hundreds of objects and images and and I had to lower the memory limit so it would render in more passes. It was locking up otherwise. It is a kind of trial and error thing.

11-04-2003, 07:48 AM
On average the scenes used here render about 30% faster with the second CPU enabled (I'm surprised that LWSN in mode 3 actually picks this setting up as well) and you can actually get savings with 4 threads depending on how your frame is set up. It seems to be the the thread division works in a manner similar to limited region, with the frame being divided up as :

thread 1 on CPU 1
thread 2 on CPU 2


thread 1 on CPU 1
thread 2 on CPU 2
thread 3 on CPU 1
thread 4 on CPU 2

If threads 1 and 3 in the latter example contain very little information, CPU 1 will fly through rendering those segments and will then sit idle whilst CPU 2 chugs away at threads 2 and 4.

The more threads you throw at a processor, the slower each thread will render out, but you might get a better efficiency given the apparent division technique above. Experimentation is the key.

You can get a more efficient usage of multiple CPUs and threads by using the raytrace transparency based speed up. Stick a transparent plane with 0% diffuse (IIRC) in front of the camera (perhaps parent it to the camera). Make it segmented (e.g. 4x4) and ensure that you have placed it so it covers the 'lens' of your camera. Enable raytrace transparency in render options and perhaps dial down the recursions to something sensible like 4 (depending on what other raytracing is happening in your scene). Also turn off the shadow options for the plane (and maybe also the fog). Try rendering now and you should find that this dramatically improves CPU usage and also shaves some time off the rendering. This is documented in these forums and probably on the lightwave tutorials repository on the web - it's not something I discovered and it is also not perfect - you sometimes get rendering problems with certain scenes.

11-04-2003, 08:29 AM
It is also worth noting that it's not worth multithreading on simple renders - you said you tried it on a scene that only takes a few seconds to render with one thread? Try it on a scene that take minutes to render - the benchmark Tracer-radiosity is a good one to try...

The problem with simple scenes is that it costs more in overhead for the processors to talk together than it does for the render to take place which is why it slows down the render...


11-04-2003, 08:54 AM
Well, BeeVee, I don't agree on that one. The problem is LW's "dumb" approach to multi threading (which is in turn a core problem of LW's rendering pipeline). The benefits of multi threading are only lost due to LW's strict paradigm.

It does not dynamically generate slices/ buckets for rendering (2 threads will always only generate 2 slices; when one of them is finished, the processor goes idle). The way LW does its poly/ Z-sorting also doesn't seem to be very multiprocessor friendly. Last but not least there are so many shaders and other plugins that simply will not work with multiple threads or right away cause crashes.

So there we are. Let's just hope things get a 1000% better in v8.