GPU-based rendering¶
In general using Cycles with GPU-based rendering is a lot faster than rendering on a multi-core CPU. For example, here are render times on one of our workstations for the scene with the 3 monkey heads used in the video from the last chapter (showing camera settings and depth-of-field):
| Type | Device | Render time* |
|---|---|---|
| CPU | Intel Core i9-12900H | 9.34 s |
| GPU | NVIDIA RTX3080 Ti | 1.32 s |
| * 960x540 pixels, 128 samples per pixel |
On this particular scene, with these settings and on this hardware using GPU rendering is roughly 7.1x faster! However, only by making a comparison on your particular system can you really find out if GPU rendering is a good option for you (for example, you might not have a very powerful GPU in your laptop or workstation).
Apart from performance there are some other aspects to consider with GPU rendering:
- When doing a GPU render your desktop environment might become less responsive, although this has become less of a problem with recent Blender versions
- A GPU usually has less memory available, which might cause problems with really large scenes
For the Cycles renderer the way to switch between CPU and GPU rendering is under the scene settings:
If you don't see a GPU Compute entry there then you first need to enable a GPU device under the global
system preferences. Go to the Preferences window (Edit > Preferences) and
then the System tab. The settings available under Cycles Render Devices are
somewhat dependent on the hardware in your system but should look a little like this:
See below for the meaning of the different (system-dependent) options.
System-specific settings¶
GPU rendering in Blender has slightly different support depending on whether you're on Windows, Linux or macOS. Below, we summarize the options you can encounter. The most up-to-date official reference for this information is this page from the Blender manual.
Windows, Linux¶
By default None will be active, meaning no GPU acceleration is used for rendering
and it all happens on the CPU.
In general, on a PC/Laptop with an NVIDIA GPU the CUDA option is available and to be preferred, although OptiX might work well as a faster alternative for NVIDIA GPUs with RTX cores.
On systems with an AMD GPU the option HIP might be available. On systems with an Intel GPU the option oneAPI might be available, with limited support Intel Arc GPUs. In that case it is definitely worth a try to see the performance of those options.
macOS¶
For macOS systems only the Metal option will be available, apart from the default None.
Metal is supported on Apple computers with Apple Silicon, AMD and Intel graphics cards.
macOS 13.0 or newer is required to support all features and graphics cards.
GPU rendering versus acceleration
This above info is about GPU rendering in Cycles on macOS, which is different from GPU acceleration for the Blender user interface and EEVEE rendering (see below). So even though your macOS system might not provide GPU rendering in Cycles, it might still work fine for Blender usage with a GPU-accelerated 3D viewport, while using CPU-based rendering for Cycles.
Limitations¶
Some limitations do apply, when using GPU rendering. But these are very specific situations that you probably won't run into anytime soon.
FAQ¶
See the FAQ in the Blender manual for some common issues when using GPU rendering with Cycles.
A thing called EEVEE?¶
When consulting other Blender materials, specifically on rendering, you may see references to EEVEE. This is another render engine available in Blender, which is different from the Cycles engine we will be using in this course.
Even though EEVEE is meant for fast and highly interactive rendering work, even more so than the Cycles preview render we showed so far, we do not use EEVEE in this course. The reasons for this are:
- We personally find Cycles to be more intuitive to work with and explain, as it is built around the path tracing algorithm, which is easy to understand while providing a very versatile set of rendering and lighting features. EEVEE's rendering setup is somewhat more complex, as it uses a combination of different techniques that needs more separate controls.
- Cycles can render both on CPU and GPU, whereas EEVEE can only render on a GPU (more specifically, it needs OpenGL)
- EEVEE doesn't support headless rendering on Windows and macOS (and only Linux since 3.4), i.e. when starting a Blender render from the command-line without showing the user interface. This is especially relevant when rendering long animations on an HPC system, or other cluster environment without a GPU-accelerated display environment.
- Cycles is more feature-complete, whereas EEVEE has some limitations compared to Cycles, although the situation improves with each Blender release
- Although Cycles and EEVEE are getting closer in features with every Blender release they are still not fully equivalent. They also use separate controls in the UI for certain features. This would mean having to dedicate extra course material on these differences
If you do like more information on EEVEE then please check this section in the Blender manual.