Why you should build a render farm
Image courtesy of Antonio Arroyo and Oliver Villar
In this article we'll explain exactly why a render farm is important using real data.
We'll get to the bottom of why they are the only way to render some projects and how you can create one using free software.
An Explanation - What is a render farm, how does distributed rendering work?
Render farms are basically groups of computers that do distributed rendering, which is where you render either a single frame or multiple frames using several computers instead of just one. We're going to go into more detail about why this is faster but for now we'll spell out the basics.
There are two main methods for distributing rendering. The first and slightly easier method frame splitting. This is where an animation is rendered by distributing its frames over several computers (those several computers make up the render farm).
Each computer renders some percentage of all the frames in the animation. We've made a simple example to follow along to where an animation of nine frames is to be rendered on three computers (three computers is not a huge render farm, but much faster than just one computer!).
With frame splitting, a "master" node usually coordinates the render, sometimes this node (a technical name for a computer) will render some of the frames, some times it acts as a manager and controls the render, but does not render any frames itself. In our example, all the computers render.
The "slave" or "render" nodes are given some of the frames of the animation to render, in this example; three frames each.
If all three computers are the same in terms of processing power, then they will all complete the render in a third of the time just one of them would take. This is why distributed rendering is so important to artists, you can scale down your render time by adding more computers.
The second method for distributing rendering is "bucket rendering" or "tile splitting". This method takes a single frame and splits it into parts to be rendered on multiple computers.
The tile splitting technique is what Crowdrender uses. As you can see from the diagram above, tile splitting works differently from frame splitting. Tile splitting breaks each frame up into parts and each computer renders one of these parts of the frame.
Tile splitting is more flexible than frame splitting for the obvious reason that tile splitting works for single frame renders. Frame splitting cannot make a single frame render faster! Tile splitting is therefore very useful for fast previewing of frames to ensure there are no errors and that the overall impression of the image is what the artist wants.
Tile splitting is not without its own problems, however. Where there is a lot of compositing required, only frame splitting can accelerate the compositing. This is because the entire frame is available on each node and in compositing, you generally need to have the entire frame.
In tile splitting, compositing usually has to be done on the master node when the tiles from each slave node are received and the entire image is finally available. This means that when using tile splitting the compositing pass must be done on the master and is therefore slower.
Knowing just these details about each technique will help immensely in having a good final render experience! For example, if you have a heavy compositing pass, frame splitting may be a better choice.
An Example, why its so important to have a render farm anyway?
We conducted a benchmark test using a project from Antonio Arroyo (see the image above!). The test was simple, the baseline was a single computer rendering the scene. For this baseline test, we used a macbook pro with a fifth generation i5 processor operating four threads.
Then, the variant for the test. We used Crowdrender to do a tile split render (because we did just one frame) using the macbook pro as master and five other computers as slaves. The other slave nodes contained similar equipment, each had four threads and similar RAM (though the CPU's were from previous generations and so clock speeds and other features were less advanced than that of the MacBook).
For the test we varied just the number of samples. Quite simply the more samples, the higher the quality of the render and the slower the image takes to complete.
Here are the results, plotted as samples (x-axis) vs render time in minutes:seconds.milliseconds we also repeated the results in a table format so you can see the exact numbers for your self.
The results for just 50 samples are:
with crowdrender : 1min 07 secs
without : 2 min 54 secs
The results for 100 samples are:
with crowdrender : 1 min 30 secs
without : 4 min 39 secs
The results for 200 samples are:
with crowdrender : 2 min 23 secs
without : 9 min 06 secs
the results for 500 samples are
with crowdrender : 5 min 12 secs
without : 19 min 40 secs
the results for 1000 samples are
with crowdrender : 10 min 06 secs
without : 39 min 27 secs
So after reviewing the results, you can see that as samples increase, the render time for both tests increases in roughly a straight line. But, the results for distributing the render are much, much better. For 1000 samples, distributing takes only 1/4 of the time to render.
What is really great about this is that with each computer you add, you will see a further reduction in the rate at which render times increase with increasing samples. In other words, the green line gets flatter.
Render farms are not just about speed
The results also suggest something else, that you can increase quality without increasing render time by using more computers. If you look carefully at the chart above, you'll see that 1000 samples (using Crowdrender and five machines) takes about the same time as one computer doing 250 samples. Distributing the render gave us four times the samples for a negligible increase in render time. If we added more computers, we could increase the samples further and get better quality images.
For high quality renders, with lots of samples or higher resolutions, it makes a lot of sense to use distributed rendering. Render times grow too quickly with just a single machine, even for a very powerful one.
Building a render farm vs building an epic workstation
It can be tempting to think, "why not just make one really fast machine"? After all, building a render farm can seem daunting, there's the added cost of specialised software, the cost of the network, and duplication of parts for each node in the farm. Perhaps just putting all those resources into one machine would be better?
The problem is that you hit a bottleneck very quickly in the number of CPU's you can put into one system (or GPUs). For top end workstations, you quickly find that you can get dual socket motherboards, so two CPUs max. Go for server motherboards and you can get four socket CPUs, but the cost starts to climb very quickly.
The cost of more performance from a single workstation starts to climb steeply towards the top end of the performance curve. Check this out.
Charts courtesy of www.cpubenchmark.net
The chart above shows CPU rating using passmark vs cost in USD. The blue arrows are a hypothetical example considering a system that scores 10,000 in passmark. Lets assume we want to increase our computing power by a factor of three; which corresponds to the earlier example of reducing render times by three times using distributed rendering. Only this time we want to build a single machine that can achieve this reduction.
We want to achieve a score of 30,000. The CPU with a score of 10,000 in passmark costs USD300 so we need three of these (in an ideal world where we can simply multiply their scores like this!).
If we now look at the chart on the right (which contain dual CPU configurations) then we can see that the only data point we have is at roughly USD5600! This means that to increase our computer power in a single system by three times, we have to spend 17.6 times the cost of our original CPU that scored 10,000!
We could get similar performance if we distributed the task we wanted to run over three systems, each with a USD300 processor. The cost of the CPUs would only be $900. This is 5.2 times less than a single system with dual CPUs.
This is just the cost of the CPUs though. One uber powerful system only needs one power supply, motherboard, case, OS, RAM and so on. Having three systems means duplicating these costs.
This is where it gets a little complicated, would those three systems be less than the one uber powerful one? The answer is it depends! There are a lot of ways to configure all these systems, its possible in some cases that the three systems could cost more than the single one.
So it seems that for computing power that's equivalent to a 30,000 passmark score, you may be better off distributing in some cases. BUT, what about cases where you want or need a system with a score much higher?
Suppose you wanted or needed a system that had combined performance that could create a score of one million. Now the only way to get there is distributing (check the chart again, 30,000 is as high as it goes!). There is not likely to be any single machine setup that could achieve arbitrarily higher performance.
The point being made here is that one single system is finite in its computer power. This means you're limited. But, if you can connect your computer together with others, you can overcome this limitation, this is the power of distributing and the main reasoning behind building a render farm.
How you can do this with Crowdrender
Our software works to allow you to easily distribute rendering in blender, it also is free and takes only three to four minutes to setup on each computer. Once running, you can easily render any blend file on multiple computers.
Here are the steps:
1. Download the free addon
2. Install the addon on each computer you want to use to render
3. Connect and start rendering
Thats it. For the full documentation, you can visit this link -> https://www.crowd-render.com/documentation-v016
To download the addon you can visit this link -> https://www.crowd-render.com/download
(you'll need to register first, but you'll get access to free software if you do :) )