Update January 2019: One year after the initial post, we ran the battery of tests again, using the latest Beta version of Blender 2.80 and the official 2.79b release. The visual quality has improved significantly and now the 2.80 renders look very close to the 2.79 ones. As we have upgraded our infrastructure, we added the new GPUs to the mix as well. Read below for the charts and our comments.
The upcoming major release of Blender – version 2.80 – has a lot of buzz surrounding it. And for good reason, too. There’s the brand new Eevee engine, showing a lot of promise. And there is a truckload of new features – new grease pencil, workspaces concept, layers and collections, and many others. On the performance side, there are also significant improvements, and a notable addition is the new hybrid render mode. This allows rendering using both the CPU(s) and the GPU(s) from the same machine, promising speed improvements in all Cycles renders.
The hybrid rendering mode is indeed an interesting feature. It has been present in V-Ray for a while with good results. So, naturally, we were excited to see it come in Blender for Cycles, too. Because it so happens that there are a large number of GPU machines in our backyard, that also have pretty powerful CPUs, we decided to put the new feature to the test.
We used the same official benchmark suite as in our previous tests. Before moving to the results, a note regarding Blender 2.80: the currently available version is beta and not a final release. It’s still work in progress and the resulted renders have a number of issues. I’ll provide more details for each one where it is the case.
The test configurations are the ones used in our on-demand and Studio plans on our render farm:
- The old GPU servers: Dual NVidia K520 boards (a total of 4 GPUs per server) and dual Xeon E5-2670 CPUs
- The new GPU servers: Dual NVidia K80 boards (a total of 4 GPUs per server) and dual Xeon E5-2670 CPUs
- The CPU servers: Dual Intel Xeon E5-2670 v2, 20 cores, 40 threads
The Blender versions used for the test:
- Blender 2.79b (the latest official release available at the moment)
- Blender 2.8.35 beta release
All the tests were done from our web interface and ran several times. The numbers represent the best time obtained for each file. Less is better.
The color coding is the following:
- CPU servers are represented in blue
- The old GPU servers are represented in orange
- The new GPU servers are represented in green
- Blender 2.79b results have a patterned background. Blender 2.80 results have a solid background.
That being said, let’s see the numbers:
1. BMW27, 960 x 540 px, 1,225 Samples (35 squared)
Benchmark 1 – BMW . Render time in h:mm:ss, lower is better
As you probably know, this scene is derived from Mike Pan’s famous ‘BMW’ one. It’s the first test in the batch, and also the simplest one. The render times show that Blender 2.80 is faster than 2.79b, even when rendering only on CPU or only on GPU. Interestingly, when using both CPU and GPU for rendering in 2.80, there is no speed increase compared to GPU-only.
2. Classroom, 1,920 x 1,080 px, 300 Samples
Benchmark 2 – Classroom. Render time in h:mm:ss, lower is better
The second benchmark, Classroom, renders fastest with the CPU+GPU combination. 2.80 is again natively faster than 2.79b. There are some output differences in lighting and details between the two. But this time the images are comparable (as opposed to the previous tests with the early 2.80 version). Hover over the image below to see the differences:
3. Fishy Cat, 1,002 x 460 px, 1,000 Samples
Benchmark 3 – Fishy Cat. Render time in h:mm:ss, lower is better
The Fishy Cat file is the first one from the test suite that has a significant amount of hair. In the Blender versions up to now, this caused the GPUs to underperform – most likely because of a lack of optimization for that particular piece of code. In 2.80, this changes – you can see that the GPU server becomes faster than the CPU one for the first time. The CPU+GPU combination is again slower than the GPU alone.
This file also shows a few differences between the 2.8 and the 2.79 renders. They are not so dramatic as in the previous case, but still, the images are not identical.
4. Koro, 720 x 1,280 px, 500 Samples
Benchmark 4 – Koro. Render time in h:mm:ss, lower is better
The Koro benchmark is another example of the GPU code improvements. While in our previous test the GPU renders were the slowest, now they are catching up. And again, the CPU+GPU render is not the fastest here. We did several tests to confirm this, and the numbers varied by quite a lot. I’m assuming this is caused by the way in which various tiles are assigned to the CPU or to the GPU during the render. In any case, the results are promising here too.
The resulted images show differences here as well between 2.79b and 2.80- see below.
5. Pabellon Barcelona, 1,280 x 720 px, 1,000 Samples
Benchmark 5 – Pabellon Barcelona. Render time in h:mm:ss, lower is better
The Pabellon scene brings a different kind of behavior – here, Blender 2.80 is slower than 2.79b in identical conditions (only CPU or only GPU). This is consistent behavior observed in our first test one year ago as well. Only the new GPU machines can shift the balance. And the new version races ahead in the CPU+GPU setup. Again, some differences in the scene are present.
6. Victor, 2,048 x 858 px, 600 Samples
Benchmark 6 – Victor. Render time in h:mm:ss, lower is better
The Victor scene was tested only on CPU, last time. Now the new GPUs can render the scene because of the larger amount of RAM, and you can see the results above. The numbers show a significant speedup in 2.80, both on CPU and on GPU. The scene quality has improved a lot in 2.80 compared to the initial test from one year ago.
Closing thoughts
The improvements between the early alpha version of Blender 2.80 and the current beta are clearly visible. The CPU+GPU hybrid rendering works well, and the results are consistent with a ‘normal’ render (either CPU-only or GPU-only). Plus, there seems to be a significant amount of work put into optimizing the entire rendering engine. I’m not sure whether this is a side effect of the Eevee implementation or a side effect of the AMD-sponsored optimization for their cards, but it’s working. Kudos to the entire dev team for it! There is still room for optimization in the CPU+GPU rendering for now. The hybrid mode doesn’t make use of all the CPU threads, and the render time can vary significantly, most likely depending on what tile has been allocated to CPU or GPU. I’m confident that the performance will improve in the next releases, though.
As a side note, when doing this battery of tests, I’ve noticed that from version to version Blender is getting faster. I’ve made this observation first about four years ago, in one of the first speed tests we’ve done. I’m really glad to see that the trend continues. And this is more impressive considering that new features are being added in each release. Trust me, I have been doing a fair share of programming myself – this is impressive 🙂
I’m looking forward to seeing the performance figures for the first official release of Blender 2.80. Until then, if you decide to use it, keep in mind that it’s a beta release at this time. It’s considerably more stable than the alpha, but there may still be the occasional issue here and there. Also, if you are planning a switch, check if the plugins you normally use work with 2.80. The API changes in the new version can break compatibility, so the plugin developers will need to make new releases.
As I was writing the closing thoughts, it just hit me: now the Victor scene will fit in the RenderStreet One monthly plan (with the time extender option). So someone using that plan could probably render the entire Cosmos Laundromat animation scene (a quite heavy and demanding one) for only $100. Or you can render it on the new GPU servers for the fastest delivery possible. Isn’t technology awesome? 🙂
