Date: June 8, 2020
Author(s): Rob Williams
To greet the launch of the Blender 2.83 release, we loaded up our test rigs to generate fresh performance numbers. For rendering, we’re going to pore over CPU, GPU, CPU and GPU, and NVIDIA’s OptiX. For good measure, we’ll also look at viewport frame rates, and the impact of tile sizes with Cycles GPU rendering.
With the launch of Blender 2.83, we’re reminded once again that time really flies. Before we’ll know it, it will have already been a year since 2.80 released – and remember just how long that took to land? While that release was a massive update over 2.79, the Blender Foundation hasn’t slowed down in its development. Each successor release has had notable features, and 2.83 is no different.
Due to the amount of time it takes to generate in-depth performance data for Blender alone, across CPU and GPU, and the fact that performance doesn’t always change much from one release to another, we like to wait a few iterations before diving in. Well, with 2.80 having released last summer, we’re definitely due for a fresh set of results.
One of the most notable aspects of 2.83 is that it’s an LTS (long-term support) release. Many Blender users may eagerly update with each new release, but if quick adoption is out-of-the-question, those users can relax, knowing that the LTS will be supported for up to two years. Any updates that hit it will be related to bug and security fixes. The next mainline release will be 2.90, due this August.
To get a full overview of features added to Blender 2.83, we’d suggest looking through the release notes. The Blender Foundation does an amazing job of showing off new features, and not to mention, cluing you into their existence in the first place.
Of note, 2.83 introduces OpenXR and scene inspection for VR use – a major addition that will be built up with each new release. Grease Pencil has also been overhauled for 2D animation, while Eevee has seen a numbers of added features, like high-quality normals and hair transparency. AI denoising has also gained another option, thanks to NVIDIA’s OptiX (RTX hardware required). This is all barely scratching the surface, so definitely check out the release notes and video above.
For this article, we’re going to explore both rendering and viewport performance. On the rendering side, we’re evaluating CPU only, GPU only, CPU + GPU heterogeneous, and also NVIDIA’s OptiX. For viewport, we’ve swapped out our complex scene with a more modest replacement, of a detailed game controller.
Here’s the full list of hardware being tested for this article:
|CPUs & GPUs Tested in Blender 2.83|
|AMD Ryzen Threadripper 3990X (64-core; 2.9 GHz; $3,990)|
AMD Ryzen Threadripper 3970X (32-core; 3.7 GHz; $1,999)
AMD Ryzen Threadripper 3960X (24-core; 3.8 GHz; $1,399)
AMD Ryzen 9 3950X (16-core; 3.5 GHz; $749)
AMD Ryzen 9 3900X (12-core; 3.8 GHz; $499)
AMD Ryzen 7 3700X (8-core; 3.6 GHz; $329)
AMD Ryzen 5 3600X (6-core; 3.8 GHz; $249)
AMD Ryzen 3 3300X (4-core; 3.8 GHz; $120)
AMD Ryzen 3 3100 (4-core; 3.6 GHz; $99)
Intel Core i9-10980XE (18-core, 3.0 GHz; $999)
Intel Core i9-10900K (10-core; 3.7 GHz; $499)
Intel Core i5-10600K (6-core; 3.8 GHz; $263)
Intel Core i9-9900K (8-core; 3.6 GHz; $499)
|AMD Radeon VII (16GB; $EOL)|
AMD Radeon RX 5700 XT (8GB; $399)
AMD Radeon RX 5600 XT (6GB; $279)
AMD Radeon RX 5500 XT (8GB; $199)
AMD Radeon RX Vega 64 (8GB; $EOL)
AMD Radeon RX 590 (8GB; $199)
NVIDIA TITAN RTX (24GB; $2,499)
NVIDIA GeForce RTX 2080 Ti (11GB; $1,199)
NVIDIA GeForce RTX 2080 SUPER (8GB, $699)
NVIDIA GeForce RTX 2070 SUPER (8GB; $499)
NVIDIA GeForce RTX 2060 SUPER (8GB; $399)
NVIDIA GeForce RTX 2060 (6GB; $349)
NVIDIA GeForce GTX 1660 Ti (6GB; $279)
NVIDIA GeForce GTX 1660 SUPER (6GB; $229)
NVIDIA GeForce GTX 1660 (6GB; $219)
|Motherboard chipset drivers were updated on each platform before testing.|
AMD CPU: All chips were run with DDR4-3600 16GBx4 Corsair Vengeance.
Intel CPU: All chips were run with DDR4-3200 16GBx4 Corsair Vengeance.
All GPU testing was done with our Intel Core i9-10980XE workstation.
AMD Radeon Driver: Adrenaline 20.5.1
NVIDIA GeForce & TITAN Driver: GeForce 446.14
All product links in this table are affiliated, and support the website.
We included some workstation graphics cards in our testing when we looked at Blender 2.80 last year, but we skipped them this time due to the fact that having them only adds noise – and not in the rendering sense. As an example, an RTX 6000 is going to perform little different from a TITAN RTX, as both have the same core configurations. There are no ProViz-specific optimizations that we know of exclusive to AMD Radeon Pro or NVIDIA Quadro.
There have been a couple of new projects to usher into this performance look, replacing some of old. First up is a new Cycles test of a game controller that we found on reddit last month, made by ftobler. This project is open-source, and would be a great way for new users to poke around and understand how an animated project can come together. The second is Mr. Elephant, a project updated for Eevee and designed by Glenn Melenhorst to accompany a children’s book he wrote.
As we’ll see with some of the performance results ahead, rendering to only a CPU isn’t going to be the best choice for most people. If you happen to have a beast chip like AMD’s Ryzen Threadripper 3990X, which offers 128 threads, then you’ll be able to effectively topple a top-end graphics card like NVIDIA’s TITAN RTX. That’s ignoring use of NVIDIA’s OptiX, which we’ll see numbers for soon.
For a typical Blender user, we wouldn’t recommend necessarily going with a high-end CPU unless you have external needs for one. If you’re a money-is-no-object type of person, then you’ll be happy to see some of the heterogeneous results coming up.
This all being said, you don’t want to go too “low-end” when choosing a CPU, even if you primarily render to the GPU in Blender. There are a number of hard-to-test intangible factors when it comes to CPU performance, such as physics simulations, which for the most part are single-core processes (although this is being updated in the 2.90 release). We’d suggest a bare minimum of eight cores nowadays, to give yourself some breathing room. Blender probably isn’t the only thing you do on your workstation, so any CPU choice should also hinge on those other workloads. You can check out a full CPU performance look on many of these chips in our Threadripper 3990X evaluation.
We’ve said it before, but it’s always interesting how differently GPUs (or CPUs) can scale from one project to the next. The BMW project is really old by today’s standards, but it’s such a de facto and simple test, we continue to use it to see how hardware behaves with a modest workload. There, NVIDIA seems to dominate, but AMD strikes back hard in the more complex Classroom scene. The Radeon VII might not be readily available, but it handles that Classroom project really well. It’s not the first time we’ve seen that scaling.
As for the Controller scene, it behaves somewhat like the BMW project, with the TITAN RTX comfortably sitting on top. There are some odd arrangements, though, such as the 2070 SUPER placing ahead of the 2080 SUPER, and that’s something we just have to say c’est la vie to. This isn’t the first instance where we’ve seen those two GPUs reverse their expected order, but based on the Classroom and Mr. Elephant tests, odd scaling like that is rare in Blender.
Speaking of Mr. Elephant, with this Eevee brute-force test (1,000 samples is overkill), we can see NVIDIA has strengths here, which means that your rendered animations will complete quicker on GeForce. Eevee can’t take advantage of NVIDIA’s OptiX (yet), but the Turing architecture has some clear optimization for these types of workloads to begin with, with even the lowbie 1660 SUPER placing just behind AMD’s 5700 XT.
It’s worth pointing out that Eevee is a raster render engine like that used by games, rather than ray traced, but is built around OpenGL 3.3. This makes the engine a bit out of date compared to OpenGL 4.5 and Vulkan, so performance is not ideal. There are plans to transition over to Vulkan, which also brings the benefit of ray tracing and additional performance improvements, but this is unfortunately not coming any time soon. The reason for OpenGL 3.3 is because of macOS, since that is the latest supported version of OpenGL before the Metal API started to emerge. AMD’s Radeon ProRender, a plugin and alternative render engine for Blender, will at least allow GPU rendering for Mac users because of its support for the Metal API.
In previous Blender performance looks, we’ve included a hybrid rendering test with only one GPU, but we’ve always wondered how the scaling would look if we threw a more modest option in there. Thus, we decided to test both the RTX 2060 SUPER and RTX 2080 Ti in these modes, to see if we can find some perfect blend of CPU and GPU.
It’s immediately clear that if you can render to both the CPU and GPU, you should do it – unless, maybe, you have an NVIDIA OptiX GPU that’s still faster. What we can ultimately glean here is that there’s little point in opting for a huge CPU if you have a competent GPU – but, it’s good to see that you will in fact still see gains if you do decide to get a big CPU.
It’s neat to see even the low-end four-cores doing well once a GPU is added in, but as mentioned earlier, we wouldn’t ever recommend such parts for a serious workstation. You want some breathing room. If your CPU choice doesn’t impact Blender all too much, you need to consider all of your other workloads, and not to mention general multi-tasking performance. You want a faster frequency CPU for a snappier OS, and more cores for multi-threaded workloads, like video encoding, or even compression.
Radeon can do heterogeneous rendering as well, but we’ve never had luck with it in Cycles. In previous testing, we encountered a black screen crash that would occur, and sadly, that didn’t change with our latest attempt. It’s worth noting that AMD’s Radeon ProRender supports heterogeneous rendering, but we do not have a project to test with it.
When accelerated by NVIDIA’s RTX series of graphics cards, the performance of its OptiX rendering engine can be dramatically improved, as highlighted by the charts above. By itself, 38 seconds for the BMW project with the TITAN RTX is impressive, but enabling OptiX manages to shave that down further to 21 seconds. A lesser gain is seen in the Classroom test, yet it’s still a major one.
It’s important to note that NVIDIA’s OptiX only works with Cycles, and while it could support Eevee in the future, our above performance suggests that there might not be a ton to gain, as the Turing architecture accelerates that workload quite a bit already. But, we’d like to be surprised.
At the moment, OptiX doesn’t work out-of-the-box with every single Cycles project you’ll come across. Interestingly, the Controller project we added to this suite won’t use OptiX correctly, as AO and bevel shaders are not yet supported (that will change). If you want to download official projects that work with OptiX, we’d suggest BMW, Classroom, or The Junk Shop.
On the next page, we’ll explore tile size performance variations, as well as viewport frame rates and AI denoising.
Throughout Cycles’ life, there have been general rules for choosing the right tile size for rendering, at least initially. For CPU, 16×16 or 32×32 has been suggested, as it’s not going to choke the entire chip by doling out too much work at once. GPUs are more capable of large parallel projects, so 256×256 has been the go-to, although 512×512 and higher has been possible in recent years.
The tile size dictates how big of a batch of work a CPU or GPU will take on at once. In truth, the defaults that are set are almost assuredly going to be suitable, but if you’re desperate for more performance, it might be worth tweaking the size a bit and running your own quick tests. For a while now, this tweaking has been less important, something that our initial tests showed, as changing tile sizes often didn’t result in dramatic time differences between renders. However, there are a few occasions where it does, and it’s a trap we fell into in this round of testing.
We’ve taken a look at tile size performance in the past, but made the mistake of testing only one vendor GPU, ignorant of the fact that there is different behavior between them. So, for the performance below, we loaded up the Classroom scene and tested 8~1024 tiles on both the RTX 2060 SUPER and RX 5700 XT – two $400 GPUs.
|AMD RX 5700 XT||NVIDIA RTX 2060S|
|8×8 Tiles||23m 10s||5m 30s|
|16×16 Tiles||7m 00s||4m 40s|
|32×32 Tiles||2m 47s||4m 31s|
|64×64 Tiles||1m 44s||4m 22s|
|128×128 Tiles||1m 36s||4m 23s|
|256×256 Tiles||1m 35s||4m 29s|
|512×512 Tiles||1m 36s||4m 39s|
|1024×1024 Tiles||1m 36s||5m 05s|
|Note||Classroom project used.|
There are just a handful of results here, but there’s still a lot to chomp on. On Radeon, it looks as though using too low of a tile size choice will absolutely ruin your performance. But then, after a certain point, the performance doesn’t change much at all, at least up to 1024×1024. We also tested 1536×1536, and on both vendors, the performance got just a bit worse, compared to 1024.
Ultimately, 256×256 worked best for AMD with this particular project and on this particular GPU, which is great, since that’s what all of our GPU tests are locked-in at. NVIDIA’s 2060 SUPER suffered a little bit at 256×256 vs. its optimal 64×64, but only by a smidgen. Ten seconds difference will matter a lot if we’re talking about animation; again, you’ll want to do your own testing if you want to lock in the perfect tile size. While we used factors of eight in our testing here, you can choose any multiple you want. It does need to be stressed that different projects will behave differently with alternative tile sizes, and mixed render modes when using the CPU and GPU will need to be weighted with a smaller tile size for the CPU to work efficiently.
In our look at Blender 2.80 last summer, our viewport test involved a complex scene – almost too complex, as the results given didn’t bode well for any GPU at 4K. With this go, we decided to swap out our old test with the new Controller scene, as it looks great, and won’t make low-end GPUs croak.
The results above reflect the Material Preview (LookDev) mode, which is somewhat of a stop-gap between a real render and one that’s “good enough”. You can’t realistically roam around a rendered scene, but once the shaders are compiled, you can easily do that with Material Preview – even during animation playback.
We’ve seen NVIDIA show off its strengths well with our viewport tests in the past, and even with this different project, nothing changes. What we do see, though, is that at 1080p, the top-end GPUs don’t treat it much differently than 1440p, although greater deltas will be seen as you move down the stack. At 4K, the top GPUs can hit 60 FPS, while the lowbie RX 5500 XT delivers 15 FPS.
With that onslaught of performance data behind us, we hope you’re better informed about what hardware you should be going after. Like most ProViz work, how you use Blender can dictate which vendor CPU or GPU to go with. Some may prefer a beefy CPU and modest GPU due to external workloads demanding lots of CPU threads; or, someone focusing on GPU rendering could go with a high-frequency but modest core-count CPU (eg: eight).
Calling eight cores “modest” might seem a bit off, but AMD’s Ryzen series has made eight-core CPUs available to the masses for over three years, and if you’re any sort of heavy multi-tasker, those extra cores will make a difference. If you’re hoping to get important work done on your machine, you won’t want to slow down your general use.
Users can get away with lesser hardware as long as they know the limitations. Today, even a 6-core Ryzen 3600X (~$249 USD) and RTX 2060 SUPER (~$399 USD) would be a powerful combination for the price, but you also need to look to the future, and set expectations for how long it will take before that hardware will be in need of a replacement. Naturally, if you’re still unsure of what to do, feel free to leave a comment below.
On the CPU rendering side, core count matters more than anything, at least with rendering, but core-for-core, AMD still does manage to eke ahead of Intel in each of our match-ups (although we don’t have as many Intel CPUs as we do AMD). Notably, AMD’s 16-core 3950X (~$749 USD) manages to beat out Intel’s 18-core 10980XE (~$999 USD).
For GPUs, it’s impossible to ignore the strengths of NVIDIA’s GPUs across all tests. There are many scenarios where AMD is strong, but from an overall standpoint, NVIDIA delivers strong performance in every metric we test. That includes Cycles rendering with or without OptiX acceleration, Eevee still or animation rendering, and viewport frame rate.
Part of the reason for weaker AMD performance may be the lack of may be lack of optimization for AMD’s architecture. Radeon ProRender is a good alternative to Cycles if you build your project around it, as simply converting your existing Cycles project to ProRender won’t always work. Even NVIDIA GPUs can use ProRender (and quite well, based on previous testing).
On the topic of OptiX, Blender 2.81 introduced us to rendering images through NVIDIA’s accelerated API, while 2.83 now adds AI denoising to the mix. This new feature exclusively affects the viewport, allowing RTX owners to use their GPU’s Tensor cores to speed-up in-place renders. The first image in the slider above is of Blender’s Material Preview mode (introduced in 2.80). The second image is of a 30 second CUDA render, while the third is a 10 second render with AI denoising enabled.
The coolest thing about the OptiX denoising is just how fast it takes place. For a few seconds, you’ll see an image iterate a few samples, and then it reaches a point where it effectively pops to the end result. How accurate this type of viewport render will be depends on countless variables, and in some cases, using the look development mode might be suitable enough. As with all things AI, this feature’s effectiveness will improve over time.
As mentioned in the intro, the next major release for Blender will be 2.90, due in August. We’re not sure at this point all of what it will introduce, or whether it will be worth retesting for, but we’ll start to eye things once that version gets closer. As always, if you have questions, comments, or suggestions, we welcome you to comment below.
Copyright © 2005-2020 Techgage Networks Inc. - All Rights Reserved.