March 31, 2022 Rosie Dinh

Best GPU memory Optimization techniques on Redshift 3D

Redshift 3D supports a set of rendering features not found in other GPU renderers such as point-based GI, flexible shader graphs, out-of-core texturing and out-of-core geometry! One of challenges with GPU is memory management. There are two main issues: First, the GPU has limited memory resources. Second, no robust methods exist for dynamically allocating GPU memory. Redshift 3D has to partition free GPU memory between the different modules so that each one can operate within known limits which are defined at the beginning of each frame. Redshift 3D also uses “geometry memory” and “texture cache” for polygons and textures respectively.

Additionally, Redshift needs to allocate memory for rays. Because the GPU is a massively parallel processor, it constantly builds lists of rays and dispatches these to the GPU. The more rays we can send to the GPU in one go, the better performance is. For example, a 1920×1080 scene using brute-force GI with 1024 rays per pixel needs to shoot a minimum of 2.1 billion rays! And this doesn’t even include extra rays that might be needed for antialiasing, shadows,etc. Having all these rays in memory is not possible so Redshift splits the work into ‘parts’ and submits these parts individually so we only need to have enough memory on the GPU for a single part.

Finally, certain techniques such as the Irradiance cache or Irradiance Point cloud need extra memory during their computation stage to store the intermediate points. How many points will be generated by these stages is not known in advance so a memory budget has to be reserved. The current version of Redshift does not automatically adjust these memory buffers so, if these stages generate too many points, the rendering will be aborted and user have to go to memory options and increase these limits.

How Redshift 3D Partitions Memory

From a high-level point of view the steps the renderer takes to allocate memory are the following:

  1. Get the available free GPU memory
  2. If we are performing irradiance cache computations or irradiance point cloud computations, subtract the appropriate memory for these calculations (usually a few tens to a few hundreds of MB)
  3. If we are using the irradiance cache, photon map, irradiance point cloud or subsurface scattering, allocate space for that memory
  4. Allocate ray memory
  5. From what’s remaining, use a percentage for geometry (polygons) and a percentage for the texture cache

The Memory Options in Redshift 3D

Inside the Redshift rendering options there is a “Memory” tab that contains all the GPU memory-related options. These are:

1. Automatic Memory Management

This setting will let Redshift analyze the scene and determine how GPU memory should be partitioned between rays, geometry and textures. Once this setting is enabled, the controls for these are grayed out. We recommend leaving this setting enabled, unless you are an advanced user and have observed Redshift making the wrong decision (because of a bug or some other kind of limitation).

2. Percentage of GPU memory to use

By default, Redshift reserves 90% of the GPU’s free memory. This means that all other GPU apps and the OS get the remaining 10%. If you are running other GPU-heavy apps during rendering and encountering issues with them, you can reduce that figure to 80 or 70. On the other hand, if you know that no other app will use the GPU, you can increase it to 100%.

3. GPU memory inactivity timeout

As mentioned above, Redshift reserves a percentage of your GPU’s free memory in order to operate. Reserving and freeing GPU memory is an expensive operation so Redshift will hold on to this memory while there is any rendering activity, including shaderball rendering. If rendering activity stops for 10 seconds, Redshift will release this memory. It does this so that other 3d applications can function without problems.

4. Irradiance Point Cloud Working Tree Reserved Memory

This is the “working” memory during the irradiance point cloud computations. The default 128MB should be able to hold several hundred thousand points. This setting should be increased if you encounter a render error during computation of the irradiance point cloud. Please see more below.

5. Irradiance Cache Working Tree Reserved Memory

This is the “working” memory during the irradiance cache computations. The default 128MB should be able to hold several hundred thousand points. This setting should be increased if you encounter a render error during computation of the irradiance cache. Please see below.

6. Maximum GPU Texture Cache Size

Once reserved memory and rays have been subtracted from free memory, the remaining is split between the geometry (polygons) and the texture cache (textures). The “Percentage” parameter tells the renderer the percentage of free memory that it can use for texturing.


Say we are using a 2GB video card and what’s left after reserved buffers and rays is 1.7GB. The default 15% for the texture cache means that we can use up to 15% of that 1.7GB, i.e. approx 255MB. If on the other hand, we are using a video card with 1GB and after reserved buffers and rays we are left with 700MB, the texture cache can be up to 105MB (15% of 700MB).

Once we know how many MB maximum we can use for the texture cache, we can further limit the number using the “Maximum Texture Cache Size ” option. This is useful for video cards with a lot of free memory. For example, say you are using a 6GB Quadro and, after reserved buffers and rays you have 5.7GB free. 15% of that is 855MB. There are extremely few scenes that will ever need such a large texture cache! If we didn’t have the “Maximum Texture Cache Size” option you would have to be constantly modifying the “Percentage” option depending on the video card you are using.

Using these two options (“Percentage” and “Maximum”) allows you to specify a percentage that makes sense (and 15% most often does) while not wasting memory on video cards with lots of free mem.

7. Maximum CPU Texture Cache Size

Before texture data is sent to the GPU, they are stored in CPU memory. By default, Redshift uses 4GB for this CPU storage. If you encounter performance issues with texture-heavy scenes, please increase this setting to 8GB or higher.

8. Ray Reserved Memory

If you leave this setting at zero, Redshift will use a default number of MB which depends on shader configuration. However, if your scene is very lightweight in terms of polygons, or you are using a video card with a lot of free memory you can specify a budget for the rays and potentially increase your rendering performance. That is explained in its own section below.

Adjust Irradiance Point Cloud/ Irradiance Cache Reserved Memory

The only time you should even have to modify these numbers is if you get a message that reads like this:  Irradiance cache points don’t fit in VRAM. Frame aborted. Please either reduce Irradiance Cache quality settings or increase the irradiance cache memory budget in the memory options

Or: Irradiance point cloud doesn’t fit in VRAM. Frame aborted. Please either increase the ‘Screen Radius’ parameter or the irradiance point cloud memory budget in the memory options

If it’s not possible (or undesirable) to modify the irradiance point cloud or irradiance cache quality parameters, you can try increasing the memory from 128MB to 256MB or 512MB. If you are already using a lot of memory for this and are still getting this message, this might be because the scene has a lot of micro-detail in which case it is advisable to consider using Brute-Force GI instead.

Adjust Texture Cache Memory

When Redshift renders, a “Feedback Display” window should pop up. This window contains useful information about how much memory is allocated for individual modules. One of these entries is “Texture”.  That number reports the number of MB that the CPU had to send the GPU via the PCIe bus for texturing. Initially it might say something like “0 KB [128 MB]”. This means that “your texture cache is 128MB large and, so far you have uploaded no data”.

Redshift can successfully render scenes containing gigabytes of texture data. It can achieve that by ‘recycling’ the texture cache (in this case 128MB). It will also upload only parts of the texture that are needed instead of the entire texture. So when textures are far away, a lower resolution version of the texture will be used (these are called “MIP maps”) and only specific tiles of that MIP map.

Because of this method of recycling memory, you will very likely see the PCIe-transferred figure grow larger than the texture cache size (shown in the square brackets). That’s ok most of the time – the performance penalty of re-uploading a few megabytes here and there is typically not an issue. However, if you see the “Uploaded” number grow very fast and quickly go into several hundreds of megabytes or even gigabytes, this might mean that the texture cache is too small and needs to be increased. If that is the case, you will need to do one or two things:

  1. First try increasing the “Max Texture Cache Size”. The default it 128MB. Try 256MB as a test.
  2. If you did that and the number shown in the Feedback window did not become 256MB, then you will need to increase the “Percentage Of Free Memory Used For Texture Cache” parameter. Try numbers such as 0.3 or 0.5

Increasing Ray Reserved Memory

On average, Redshift 3D can fit approximately 1 million triangles per 60MB of memory (in the typical case of meshes containing a single UV channel and a tangent space per vertex). This means that even scenes with a few million triangles might still leave some memory free (unused for geometry). That memory can be reassigned to the rays which, as was explained earlier, will help Redshift 3D submit fewer, larger packets of work to the GPU which, in some cases, can be good for performance.

Determining if your scene’s geometry is underutilizing GPU memory is easy: all you have to do is look at the Feedback display “Geometry” entry. Similar to the texture cache, the geometry memory is recycled. If your scene is simple enough (and after rendering a frame) you will see the PCIe-transferred memory be significantly lower than the geometry cache size (shown in the square bracket). For example it might read like this: “Geometry: 100 MB [400 MB]”. In this example, this means we can use the 300MB and reassign them to Rays.

The ray memory currently used is also shown on the Feedback display under “Rays”. It might read something like “Rays: 300MB”. So, in the memory options, we could make the “Ray Resevered Memory”, approximately 600MB. I.e. add 300MB that our geometry is not using to the 300MB that rays are using. 


Hope that after this article, you can have better understanding of some advanced optimization techniques on Redshift 3d and can take advantage of them to create wonderful projects in the future. 

One interesting thing for you! iRender is a Professional GPU-Acceleration Cloud Rendering Service provider high performance machines for rendering tasks, CGI, VFX with over 20.000 customers and being appreciated in many global rankings ( e.g: CGDirector, Lumion Official, Radarrender, InspirationTuts CAD, All3DP). We are proud that we are one of the few render farms that support all software and all versions. Users will remotely connect to our server, install their software only one time and easily do any intensive tasks like using their local computers. Redshift 3D users can easily choose their machine configuration from recommended system requirements to high-end options, which suit all your project demands and will speed up your rendering process many times.

High-end hardware configuration

  • Offering the most powerful graphic card currently, RTX 3090. The servers range from Single and Multi-GPU servers: 1/2/4/6/8 x RTX 3090 with 24 GB vRAM capacity, fitting to the heaviest images and scenes. NVLink/SLI requested for bigger vRAM.
  • A RAM capacity of 128/256 GB.
  • Storage (NVMe SSD): 512GB/1TB.
  • Intel Xeon W-2245 or AMD Ryzen Threadripper Pro 3955WX CPU with a high clock speed of 3.90GHz.
  • Additionally, iRender provides NVLink (Request) which will help you increase the amount of VRAM to 48GB. This is a technology co-developed by Nvidia and IBM with the aim of expanding the data bandwidth between the GPU and CPU 5 to 12 times faster than the PCI Express interface. These servers are sure to satisfy Blender artists/ studios with very complex and large scenes.

Let’s see rendering tests with Redshift on multi-GPU at iRender:

If you have any questions, please do not hesitate to reach us at any time. Register an ACCOUNT today and get FREE COUPON to experience our service. We are availabe 24/7 to support you!

Thank you & Happy Rendering!

Source:Redshift documentation

Related Posts

The latest creative news from Redshift Cloud Rendering.

, , , , , , , , , , , , , ,

Rosie Dinh

Hi everyone. Being a Customer Support of iRender, I always hope to share and learn new things with 3D artists, data scientists from all over the world.


Autodesk Maya
Autodesk 3DS Max
Cinema 4D
Daz Studio
Nvidia Iray
Unreal Engine
And many more…


Hotline: (+84) 912-785-500
Skype: iRender Support
Email: [email protected]
Address 1: 68 Circular Road #02-01, 049422, Singapore.
Address 2: No.22 Thanh Cong Street, Hanoi, Vietnam.