Blender 2.92 Linux & Windows Performance: Best CPUs & Graphics Cards

Rendering performance is undoubtedly important when it comes to retaining sanity in your workflow, but viewport performance can be equally important, if not more so. After all, the viewport is where you’ll be doing all of your actual design work, so the laggier it is, the more frustrating it will be to work with.

The release of Blender 2.80 introduced Material Preview mode, which lets users see an advanced look at their project, complete with improved shading and shadows –  without having to wait on a render every time they’re not sure something’s going to look right. Not surprisingly, which GPU you have will greatly determine your level of satisfaction with this mode.

We’ve generally only tested Material Preview for Blender viewport tests because Solid and Wireframe modes are usually CPU-bound. With 2.91, however, we encountered anomalies with AMD Radeon GPUs that crippled performance in both of those modes, although only Wireframe was looked at. Thankfully, the Blender developers squashed the bug that caused the issue in time for the 2.92 release. That inspired us to return to Wireframe testing, and also include Solid mode for good measure.

We’re using two projects for our viewport tests, so let’s start with the lighter one:

There’s quite a bit to dissect here. Overall, most of the GPUs scale as we’d expect, although it’s clear that NVIDIA has an inherent advantage. RTX’s special ray tracing features are not used in this look development mode, but NVIDIA’s architecture seems to be well-suited for it, anyway. Anything above an RX 5700 XT will deliver reasonable performance, but you may want to seek out a higher-end GPU if you want to better handle more complex projects down-the-road. We’ll touch on the weird Windows results for AMD cards a little later.

Let’s ramp up the difficulty and test out the Racing Car project:

At 4K res, this project is a bit of a brute force test compared to the Controller one, as even the RTX 3090 can’t hit 60 FPS here, despite clearing 140 FPS with the other test. Naturally, you don’t actually need 60 FPS in a viewport, but it’s undoubtedly going to offer a more satisfying experience if it’s close to that – and again, you have to think about future projects. With the case of this “brute force” test, lower resolutions will fare a lot better – as we’ll see in a bit.

Turning our attention to Linux again, we were impressed to see improvements in all cases. That’s especially so because we’re dealing with the most graphics-intensive mode, and didn’t see any difference in performance between the OSes in GPU rendering.

One set of results we found interesting between these two tests were for the RDNA and RDNA2 cards (AMD’s 5000 and 6000-series GPUs). In the Controller project, RDNA (eg: RX 5700 XT) cards experienced a much larger improvement in Linux over Windows. Or, should we say, suffer a performance hit in Windows, since it scales as expected under Linux. With the Racing Car project, it was RDNA2 (eg: RX 6800 XT) that saw that weird performance flip.

Let’s see how things change in Solid mode:

Hoo boy. Racing Car, being much more complex than Controller, shows the most expected type of scaling. Whereas Material Preview had RDNA 1 and 2 GPUs scaling differently between projects, both RDNA series see the same kind of performance regression in Solid mode for Windows. Does it matter if you have 100 or 200 FPS? Probably not, but that doesn’t make the differences less interesting!

In another chapter of the Anomaly Files, the RX 5600 XT performed very strangely in the Racing Car project in Solid (and Wireframe) mode. Somehow, that was the only GPU in this bunch to see the reverse trend between Windows and Linux – something we ended up sanity checking twice over on different days because we just couldn’t wrap our heads around it.

For the most part, there are certainly performance issues with AMD under Windows, at least with the viewport. Whether that is an issue with Blender, AMD’s drivers, or Windows in general, we can’t say. But, it is something to be mindful of.

Are you tired of looking at charts yet? No? Well good, because here are some more, taking a look at Wireframe mode in the same projects:

It may not be immediately obvious, but wireframe modes involve a lot of information, and they can actually run slower than the Solid mode. This basically comes down to object occlusion and culling being disabled, since all vertices need to be visible (this a good example of how much performance can be gained from occlusion detection).

For the sake of time, we left the 1440p and 1080p viewport testing to Windows:

As you’d imagine, using a resolution lower than 4K is going to deliver a much faster viewport, but that shouldn’t deter you too much if you’d like a higher-res screen. If your viewport uses a fraction of the total screen, it will run a lot better than if it’s taking up the entire thing. We benchmark using a full-screen viewport to stress the hardware the best we can, so it acts as a “worst case” scenario for that project and resolution.

It was also at this point we realized the mistake with using Windows only for finishing up testing with 1080p and 1440p, as it meant we saw weird issues such as how a 5700 XT was performing better than a 6800 XT, and a 3060 beat out the 6900 XT. This comes down to the issues we saw earlier with AMD and Windows in Blender. We didn’t have time to retest all results, but did some sanity checks, and found in the Controller project 1080p material preview mode, the 5700 XT jumps from 69 FPS in Windows to 112 FPS in Linux. It also bumps from 60 to 108 FPS at 1440p, with similar scaling being seen with the Racing Car scene: 17 to 27 FPS at 1080p, Windows to Linux. In general, most of the AMD GPUs are performing about 40% worse under Windows than in Linux in viewport tests. This is something we’ll have to be more mindful of in future testing, at least until Blender and/or AMD figure out what might be the cause.

In advance of conducting our reportable benchmarking for this article, testing had been done on both our Ryzen Threadripper 3990X and Ryzen 9 5950X platforms as a comparison of viewport performance scaling between CPUs. We didn’t plan to provide this info, but there are some useful things to glean:

On the previous page, we mentioned that your CPU choice for Blender should largely depend on how you use the software. If you prefer CPU rendering, you’d want a big, multi-core CPU. If you’re rendering with a GPU, and want the snappiest UI / interaction experience, modest core count CPUs with higher clock speeds can help – at least to some extent.

As you can see at the bottom of the table above, when the same GPU (RTX 3090) is tested in a 5950X 16-core platform instead of the 3990 64-core one, the Solid mode gains almost 100 FPS. Again, it doesn’t matter too much from a design perspective if you can flick the screen at 60 or 300 FPS – this ain’t a twitch-reflex shooter – but it still proves a point.

There are other aspects to CPU performance that we haven’t been able to cover, such as baking, physics, fluids, composition filters, and so on, where, for the most part, Blender is still largely single-core limited. The physics engine is going through an overhaul to be more multi-threaded, though, and it’s something we’re looking into building a test project for.

Memory is something else that needs to be considered. AMD’s Ryzen and Intel’s Core processors support up to 128GB, but their bandwidth will be limited to two-channel. The workstation-focused Ryzen Threadripper and Core X series support up to 256GB, and enjoy the extra bandwidth provided by a quad-channel memory controller. The complexity of your project, and how efficient you are with its resources, will determine how much memory you need, and whether GPU rendering will need access to system memory if its framebuffer is full. Testing these high-complexity scenes is something we’ll have to consider in the future.

Wrapping Up

Well, that was one heck of a Blender render (and viewport) bender. As it happens, Blender 2.92 brings not only many feature enhancements, but performance improvements, as well. We weren’t able to find the improved performance in our Cycles testing, either for CPU or GPU, but we did see a notable jump with Eevee across our tested stack.

One aspect of Blender performance we haven’t tackled in a while is tile sizes for CPU and GPU rendering, although that’s largely because the defaults are usually good enough. You can refer to some of our benchmarking from the Blender 2.83 deep-dive, but a good rule of thumb is that you use 32×32 for CPU, and 256×256 for GPU. Of course, if you really want to eke out the best performance, you can run your own quick tests using a region of your scene.

Blender 2.92 Splash Screen “Sinosauropteryx Prima” (Credit: Joanna Kobierska)

We’d love to say that we hope this article helps you decide on a new GPU easier, but whether or not you’ll actually be able to find what you want available for purchase is the big question. The ongoing global chip shortage (or, extreme demand, if you want to look at it that way) is horrible for most who want to build a system right now. All we can say is good luck, and we hope your attempt is rendered a success (no pun, of course.)

Before wrapping up: a quick reminder that Radeon ProRender performance in Blender can be investigated in this article. With the RTX 3060 having just been released, and AMD’s RX 6700 XT due soon, we’ll soon be publishing a fuller look at rendering and content creation performance – so stay tuned.