Tip: When dealing with VRAM issues, try rebooting the machine and restarting the render task without opening any other applications first. Some applications like browsers or After Effects can sometimes 'reserve' VRAM, making it unavailable for Redshift to use. Also, if you have multiple monitors attached to the same (rendering) GPU, consider testing a render task with only one monitor, or alternatively plug the monitors into a secondary (non-rendering) GPU if available.

In the "COMPUTE DEVICES" section of the DCC render preferences panel (shown in the example below for Cinema 4D), you can decide which GPU is allowed to render the scene. You can also see a CPU checkbox there, as it can participate in the rendering task as well. (Tip: In some cases, it can be beneficial to disable the CPU from rendering as it may be slower compared to GPU rendering. Sometimes the faster GPU might need to wait for the slower CPU bucket to finish before it can continue to the next frame.)

If you have multiple GPUs, disabling one will allow it to handle other VRAM requirements on the machine without participating in the rendering task. (Tip: If you have multiple GPUs, it's often beneficial to test rendering with only one GPU while letting the other GPU handle other VRAM requirements on the machine, and see if this is faster than rendering with both GPUs simultaneously.)

Level 1 - Available VRAM (at the hardware level )

At the top of the Redshift Log file, under “Initializing GPUComputing Module (CUDA)” we will be able to see how much VRAM you have on your GPU (at the hardware level), but also how much is left after subtracting whatever is reserved by the OS.

(see this article on where to find the Redshfit log file - https://support.maxon.net/hc/en-us/articles/16868674965788-Step-by-Step-Finding-Your-Redshift-Log-File )
 

In the example below the machine has a GPU with 8181MB of VRAM, after subtracting a little bit due to what the OS reserves, that leaves 7171MB of VRAM.

The machine below has 2 GPUs, that’s why we see this for both GPU 1 (annotated with a red letter A) as well as GPU 2 (annotated with the red letter B )

Level 2 - How much VRAM is left 

(minus software, monitors)

subtracting the current 3D application, other applications, monitors, etc.

 

Under the “Rendering blocks …” section you will be able to see additional VRAM information. 
Out of that 7171 MB of VRAM Redshift will not be able to use all of that. Some of it will be used by things such as the 3D application, the monitor etc. CUDA (The GPU driver) will tell Redshift whatever it thinks is left for Redshift to use.

Your log file will always contain a sentence called “Redshift can use up to … “

In the example below, the render engine is using 2 GPUs. A GTX 1070 and a GTX 1050 TI.

The first GPU can use up to 6056 MB of VRAM
And the Second GPU can use up to 2283 MB of VRAM.

Again, that is the available VRAM according to the driver - it already subtracted what was used by other applications, the monitor and so on.

So, based on the log text block above we know that Redshift can use up to 6056 MB of VRAM for the first GPU, and up to 2283 MB for the second GPU.

Level 3 - How much VRAM Redshift reserves/uses 

(by default 90% of the available VRAM)

 

Out of that, Redshift will (by default) reserve up to 90% for actual rendering. What is left for the system to use. In the example in the image above that is 695 MB for the first GPU and 317 for the second GPU. Again, that’s left for the system to use after Redshift reserves 90% of the available (according to CUDA) VRAM.

The memory usage is 90% by default, but that is something that can be changed in the render settings.

Sometimes if you are experiencing some VRAM issues we advise to change that from the default 90% to 70% for example. The image below shows where you can change this setting.

Going out of core

Sometimes the render requires more VRAM compared to what is available to Redshift. In cases like that the rendering task can go 'out of core' It will then use the RAM on the machine as memory to continue rendering. It will still be able to render but will be slower in comparison.

In the log file, there will always be a GPU memory section under ‘statistics’ 
In the example below, if A is larger than B, then the render task was ‘out of core’.

This simple example below is NOT out of core:

This example is going out of core. In the log file below A > B. (A is larger than B )

To summarize: When you don't have enough VRAM Redshift will start swapping the data using the system RAM which is a bit slower but it will still render, this is called going Out of Core (OoC). There are a few things that cannot go OoC like volume VDBs for instance. In scenarios like that, you will get an out of Vram error in the log.

Tip: if you go out of core due to the use of textures then you can consider using 4K textures instead of 16K textures for example. Especially when using UDIM the amount of used textures can add up quickly.

Once tessellated an object stays in cache unless the tessellation is screen-based and it's recomputed every frame (in that case it stays in cache for the frame but it's rebuilt every frame), you can of course freeze tessellation in RV but not on the final render.

It is understandable if you want your textures in the highest possible bit depth but it's pointless to save an 8bit as a 32bit hoping it's better.

Use instances as much as possible even with proxies, a copy of the proxy is still using the same amount of VRAM as the proxy, and an instance of the proxy uses almost nothing.

VRAM Errors

Sometimes you can see VRAM errors. For example:

Redshift cannot operate with less than 256MB of free VRAM. Frame rendering aborted.

or…

There is less than 128MB of free VRAM once fixed data and minimal ray memory are considered

Even though Redshift supports out-of-core rendering, it needs a certain amount of free VRAM to operate. The above messages means Redshift failed to find that minimum amount so it couldn't continue rendering.

These out-of-VRAM messages mostly happen with GPUs with limited VRAM.

As stated before, some things cannot go out of cure in the same way that geometry and textures can. VDB Volumes cannot. IC and Irradiance point cloud data also cannot go out of core. When there is no sufficient VRAM available for those Redshift will provide an error.

However, for Irradiance cache data and Irradiance point cloud data, we can force Redshift to reserve more VRAM for those in the memory section of the render settings.

NVLink

When you have two of the same GPU devices, you can also double the available VRAM using NVlink.

For more information related to running out of VRAM also see:

https://help.maxon.net/r3d/cinema/en-us/#html/Dealing+with+Out-Of-VRAM+situations.html#DealingwithOutOfVRAMsituations-SLI