CPU, GPU, and Hardware Recommendations for Redshift

How does CPU affect Redshift performance?

Certain processing stages of Redshift are dependent on the performance of the CPU, disk or network, including:

• Extracting mesh data from your 3D applicaiton
• Loading textures from disk
• Preparing the scene data for use by the GPU

Depending on scene complexity, these stages can take a considerable amount of time, which may result in a bottleneck from lower-end CPUs.

Aside from these stages, Redshift is primarily utilizing GPU resources over the CPU.

Which CPU do you recommend using for Redshift?

We generally recommend using CPUs that have plenty of single-threaded performance, and at least a mid-range quad-core CPU such as the Intel Core i5. 

If the CPU will be driving four or more GPUs or batch-rendering multiple frames at once, a higher-performance CPU such as the Intel Core i7 is recommended.

We also recommend:

• CPUs with operating frequencies of 3.5GHz or more. It’s better to have a CPU with fewer cores but more GHz than more cores and low GHz (i.e. an 8 core 2.5GHz CPU will be considerably worse for Redshift compared to a 6 core 3.5 GHz CPU). 
• CPUs with more PCIe lanes. Not all CPUs can drive 4 GPUs at full PCIe x16 speed; CPUs have a feature called "PCIe lanes" which describes how fast data can be communicated between the CPU and the GPU. Some CPUs have fewer PCIe lanes than others. 
  • For example, the Core i7-5820K 3.3GHz has 28 PCIe lanes while the i7-5930K 3.5GHz has 40 PCIe lanes. This means the 5930K can drive more GPUs and at higher speeds. 
  • When you have multiple CPUs on the same motherboard (like with Xeons), the PCIe lanes from the CPUs are combined. Dual-Xeon systems can easily drive 8 GPUs at full speed.

What motherboard should I use with Redshift?

If you’re building a computer for Redshift and anticipate adding more GPUs to it in the future, we recommend choosing a motherboard that has 4 PCIe3.0 x16 slots or more. 

Note that some motherboards will claim to have 4 PCIe3.0 x16 slots but their specifications will say something like (x16, x16), (x8, x8, x8, x8). This means if you have two GPUs, they’ll both run at x16 speed but if you have 4 GPUs, each will run at x8 speed. In other words, even though the motherboard has 4 slots, they can't all be running at full x16 speed at once.

You do not need x16, x16, x16, x16 slots, Redshift will run just fine with x8, x8, x8, x8, but there can be some cases where x16 speed would help the performance a bit. This includes DeepEXR rendering or rendering scenes that perform a lot of out-of-core rendering (i.e. cases when the GPU needs to access CPU memory). Even in those cases, don't expect a huge performance difference between a x16 and a x8 slot.

Note that, even if the chosen motherboard claims to have lots of PCIe x16-capable slots, you need an appropriate CPU to achieve this performance.

If you’ll be adding multiple GPUs per computer, prefer a motherboard with multiple fast PCIe x16 slots

Which GPU do you recommend using for Redshift?

NVidia recommendations

From the NVidia line of GPUs, we recommend the last-gen GeForce RTX2070, GeForce RTX2070Ti, GeForce RTX2080 and GeForce RTX2080Ti GPUs. Or the current-gen, we recommend the GeForce RTX3060 Ti, RTX3070, GeForce RTX3080 or GeForce RTX3090 GPUs. 

From the professional-grade GPUs, we recommend the last-gen Quadro RTX5000, Quadro RTX6000 GPUs or the next-gen Quadro RTX A6000. 

Some additional notes:

• GeForce and Quadro GPUs can be used on the same computer when working with Redshift.
• There are no considerable Redshift rendering performance differences between GeForces and Quadros.
• The Quadros can typically render viewport OpenGL faster compared to the GeForces, but this doesn't affect Redshift’s rendering performance. 
• Quadros have more onboard VRAM, which might be important if you are rendering very large scenes. 
• One important difference between GeForce GPUs and Titan/Quadro/Tesla GPUs is TCC driver availability.
  • TCC means "Tesla Compute Cluster," which is a special driver developed by NVidia for Windows that bypasses the Windows Display Driver Model (WDDM) and allows the GPU to communicate with the CPU at greater speeds. 
  • A drawback to enabling TCC is that the GPU becomes ‘invisible’ to Windows and 3D apps (such as Maya, Houdini, etc) and instead becomes exclusive to CUDA applications (like Redshift). 
  • Only Quadros, Teslas and Titan GPUs can enable TCC. The GeForce GTX cards cannot use it. 
  • TCC is only useful for Windows. The Linux operating system does not need it on account the Linux display driver doesn’t incur latencies associated with WDDM (i.e. the CPU-GPU communication on Linux is, by default, faster than Windows using WDDM)

Despite the lack of TCC on GeForce GPUs, you can still get some of the latency benefits of TCC on Windows 10 by enabling Hardware-accelerated GPU scheduling, which was first introduced in Windows 10 and NVidia drivers released in 2020. 

AMD recommendations (only for macOS Big Sur or later)

A list of AMD Supported GPUs is shown here.

The best AMD GPU rendering performance is currently offered by the Radeon Pro Vega II duo as this graphics board contains two GPU chips. The non-duo version contains a single GPU so it’s half as fast. The performance of the non-duo is roughly equivalent to the W5700X which is another GPU we’d recommend for Redshift, as it is less expensive.

How much VRAM is enough for Redshift, and what difference does it make to performance?

The general rule of thumb for Redshift (and other GPU renderers) is “the more VRAM, the better”. However, GPUs with more VRAM are also more expensive. 

Below we'll outline how Redshift uses VRAM to help you make an informed decision when choosing a GPU.

• Redshift is able to fit around 20-30 million unique triangles within approximately 1GB of video memory. If a scene contained 300 million triangles, Redshift would normally need approximately 10GB of VRAM, but even GPUs with 8GB of VRAM can render such high poly scenes with Redshift due to its out-of-core architecture (please see our online FAQ for an explanation of “out of core”). However, excessive out-of-core data access can sometimes introduce considerable performance penalties. It is, therefore, preferable to have plenty of VRAM available when rendering high-poly scenes.
• Redshift’s out-of-core tech doesn’t cover all possible types of data. Currently, Redshift cannot store volume grids (such as OpenVDB) in an out-of-core fashion. This means that scenes using many hundreds of megabytes of OpenVDB data might require a GPU with more VRAM, otherwise the frame rendering will be aborted.
• Having lots of VRAM means being able to run multiple GPU applications at once. Apps like Maya’s OpenGL viewport, web browsers, and Windows itself can consume considerable amounts of VRAM and leave little memory for Redshift to work with. 
  • A cost-effective workaround to buying a GPU with a lot of VRAM would be to instead install an additional (cheaper) GPU to be used for everything except Redshift, then buy additional GPU(s) disconnected from any monitors, resulting in their entire VRAM being available for Redshift rendering (disconnecting a GPU from the monitor is called “headless mode”).
• Remember that VRAM from multiple GPUs is not combined together. For example an 8GB GPU and an 11GB GPU do not add up to 19GB; each GPU can only use its own video memory resources.
  • The exception being if they are NVidia cards linked together with NVLink. NVLink is an NVidia technology (so it’s only supported on NVidia GPUs) which can bridge two GPUs together, enabling them to share each other’s memory. This comes at a performance penalty which might or might not be considerable in some cases. Redshift automatically detects and uses NVLink, if present.
• Opt for more VRAM if:
  • You are not going to be using an extra GPU for OpenGL/2D rendering
  • You are rendering heavy scenes (e.g. 150+ million scenes or lots of OpenVDB or particles)

Is having multiple GPUs better than one?

Redshift will render faster with multiple GPUs, but having multiple GPUs will likely require a special motherboard/CPU setup.

For more VRAM: Titan/Quadro/Tesla (for NVidia) or Radeon Pro (for AMD)

For faster render times: Multiple, cheaper GPUs (for the same cost) will offer more compute power and faster render times.

Multiple GPU scaling

When rendering with Redshift and multiple GPUs, you have two options: 

• Render a single frame using all your GPUs
• Render multiple frames at once using a combination of the GPUs

Rendering a single frame with all available GPUs can, in some cases, produce a non-linear performance gain. 

• For example: 4 GPUs might not render exactly 4x faster than 1 GPU because there’s a certain amount of per-frame CPU processing involved, which is not sped up by adding extra GPUs.
• To better explain this, consider the following example: Let’s assume that extracting scene data from Maya (which happens solely on the CPU) takes 10 seconds, and rendering takes 60 seconds to execute with 1 GPU, bringing the total rendering time to 70 seconds. 3 additional GPUs (totaling 4) would divide the 60 seconds of rendering time by 4, equaling 15 seconds-- but the 10 seconds of CPU extraction time are not affected, so the total rendering time would be 10 seconds + 15 seconds = 25 seconds vs the original 70 seconds. Resulting in it being 3 times faster instead of 4.

There are other cases where more GPUs don't help, such as loading data from disk. To make things even worse, certain CPU processing stages are single-threaded, which means that installing a CPU with many cores also wouldn’t help.

• The solution to the above problem is to render multiple frames at once. If a computer has 4 GPUs, you could render two frames at once, each frame using 2 GPUs. When you render multiple frames at once, you’re forcing your CPU to do more work (extract multiple frames at once, for example) which, quite often, improves the CPU-GPU performance ratio.
• Some render managers (like Deadline) support this Redshift feature out-of-the-box. In Deadline the feature is called GPU affinity. 

Alternatively, if you’re not using a render manager and prefer to use your own batch render scripts, here's  information on how to render from the command line and use a subset of GPUs, whic is basically what Deadline and other render managers do behind the scenes to select GPUs in Redshift.

Does Redshift support external GPU enclosures?

External GPU enclosures can be beneficial if your computer doesn’t have enough PCIe slots and also when you want your GPUs to be portable, but Redshift’s software architecture requires the GPU to communicate more frequently with the CPU compared to other GPU renderers, so the performance (latency) of the enclosure is very important.

Redshift has not done much testing with external GPU enclosures, but the ones tested Redshift had no issues, were stable, and we weren’t able to measure any performance hits compared to installing the GPUs directly on the computer’s motherboard. 

Note that not all external enclosures are suitable for Redshift, as some may introduce PCIe communication latencies, which would negatively affect Redshift’s performance. 

We recommend testing Redshift with your chosen enclosure before buying.

What PSU/Cooling suggestions do you recommend when using Redshift?

Consult with the wattage requirements of your CPU/GPU and choose an appropriate PSU.

• Low-quality PSUs or PSUs without sufficient power might cause GPU instability, crashes, and might even damage your GPU.
• Having multiple GPUs in one computer will generate considerable amounts of heat, so make sure the case is well-cooled/ventilated. 
• If ventilation isn't sufficient, the GPUs might do thermal-throttling and down-clock themselves in order to not burn out. 
  • Throttling/down-clocking means slower rendering times
  • High heat means a shorter lifespan for your electronics.

Memory

We recommend having at least twice as much CPU memory as the largest-VRAM GPUs installed on the system. 

• Example: a TitanX 12GB should have at least 24GB of RAM installed on it

If you’ll be rendering multiple frames at once, memory should be multiplied accordingly. 

• Example: Rendering 1 frame needs 16GB, rendering two frames simultaneously will need roughly 32GB.

Disk

We recommend using fast SSD drives. 

Redshift automatically converts textures (JPG, EXR, PNG, TIFF, etc) to its own texture format, which is faster to load and use during rendering. 

Those converted textures are stored in a local drive folder, so we recommend using an SSD for that texture cache folder to allow the converted texture files to be opened faster during rendering. 

Redshift can optionally not do any of this caching and simply open textures from their original location (even from network folders), but we don't recommend this.

Network and NAS

Redshift can render several times faster than CPU renderers. This means that the burden on your network can be higher too, just like it would be if you were adding lots more render nodes. 

Since Redshift caches textures to the local disk, it won't try to load textures through the network over and over again (it will only do this if the texture changes). However, other files (like Redshift proxies) are not locally cached, so they will need to be accessed over the network repeatedly. Fast networks and networked-attached-storage (NAS) typically work fine in this scenario.

Some users have reported extremely low performance with certain NAS solutions, but since there are many NAS products available in the market, we strongly recommend thoroughly testing your chosen NAS with large Redshift proxies over the network. 

• Example, try exporting a large Redshift proxy containing 30 million triangles or so (a tessellated sphere would do), save it in a network folder and then try using it in a scene both through a network path and also through a local file - and measure the rendering performance difference between the two.