MASSIVE blender GPU problem

Hi cgstrive, the Blender memory peak does not show the real VRAM usage.
I guess you need much much more the that on GPU, can you check with GPU-Z for example?

Cheers, mib

Thank you mib2berlin, your reply is very much appreciated!

I managed to render it with 2GPUS (1 process) after some optimizations which might incline RAM issues? PC has 16GB of RAM ( I do sometimes get LOW memory warning ). Taskmgr screen attached just incase.

2 threads still fail on this particular scene, they produce EMPTY frames.


I am sure i will figure this issue out, not the first time. I will try to add more system RAM and just optimize the scene… or render in CUDA_MULTI_2 mode which has slight speed penalty.

I just wanted to relate to this thread as I have rendered over 5000 frames in fullHD the past few months and had to split scenes into many render layers to make it work. VRAM utilization seems inefficient as things start failing around 4GB (on either 780 6gb or Titan 6gb). I had near full utilization with Octane even prior to 2.0 release. I want to stress that Cycles is just absolutely amazing to work with but my hope is that perhaps there will be optimization in this area in future :slight_smile:

Thank you!

Hello,

I ve run a few tests against older versions of Blender after I noticed with each new release cycles uses more and more VRAM when rendering on GPU. Here are the findings;

Test Setup:

  • Default Blender CUBE scene, 960x540 Resolution, 1000 samples, 512x512 Tiles
  • Primary Display GPU: Quadro K2200 (1x24" LCD)
  • Rendering GPU: GTX 780 Ti (no monitor attached)
  • Windows 10 Pro, 16GB DDR3
  • GPU-Z to monitor Memory Usage(Dedicated)

VRAM Usage Results:

Blender v2.76 - v2.72: 1,150MB


Blender v2.71: 590MB (50% reduction)

Comparison:

Blander Octane Edition v2.23.2 DEMO (Blender v2.75): DL 248MB, PT 263MB, PMC 311MB

Conclusion:

Cycles in Blender v2.72 to v2.76 use twice as much VRAM as v2.71 and older versions. Just going from v2.71 to v2.72 you lose close to 50% VRAM. For comparison when rendering with Octane Render it only used around 250-300MB, thats 4-5x less than Cycles 2.72-2.76 and 2x less than Cycles 2.71. Whats the problem?

Tip: If you are running out of VRAM when rendering with Cycles then you can try v2.71 and see if that helps.

We would have to look at the code to know for sure, but this could be for many different reasons. A big chuck is undoubtedly the kernel with the additions of new functionality. Another reason might be that these new features need buffers or temp storage space, like render passes? Also I imagine that tile size and/or image size makes a big difference as well. Currently Octane has issues with this if you render really large images (ex. 18000x5000) and this needs to be buffered in vram. Polys just don’t take up that much memory in comparison.

Thanks 3DjOBS for these tests.
I had thought that the problem was starting from 2.73 where there had not been many changes in Cycles. But if the problems start from Blender 2.72, there were some changes in GPU and Cycles:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Cycles

Thanks, according to Brecht Van Lommel https://developer.blender.org/T43310 the cause of vram to double in use is mainly due to the volume rendering feature that was added in v2.72, and other features.

They are working on splitting up the kernel which supposedly should see a significant reduction of vram use but could take a while. https://developer.blender.org/D1200

The vram used is the kernel size… nothing to do with the scene.

If you are compiling blender youself, edit file /intern/cycles/kernel/kernel_types.h and change the following lines

line 84 to
//#define VOLUME

line 85 to
//#define VOLUME_SCATTER

line 176 to
//#define HAIR

and recompile blender… What this will do is disable volumetric rendering and hair… It results in about 200-300mb less ram being used for the kernel as well as (approximately) 20% faster renders.

Tracker D1200 is in regards to the kernel split for OpenCL… which is already part of blender… The port over to CUDA will happen eventually but hasnt started.

Yes, even I had participated in this bug report, but they mentioned from Blender 2.73, and having seen the release notes 2.73 I was unable to find significant changes in Cycles. Now I understand the problem starts from Blender 2.72. Unfortunately I can not do tests before Blender 2.73 because Maxwell cards have support from Blender 2.73. I had not seen the latest Brecht messages in this bug report.

200-300MB is a start but you might just use v2.71 giving you 50% more vram, tho you will lose many other features.

Thanks! you are correct sir.