12
$\begingroup$

I have to render an image of 27000 x 7000 for a 150dpi print. The scene is quite big, but cycles preview and a render in 2700x7000 works as expected.

If I hit render my memory raises up to 20gb, but my cpu usage is at 5%. Why cycles does not using the full cpu power during the render process?

Here are my rendersettings:

Pathtracing
Samples:3000
Tilesize: 64x64
Bounces: Max 12 | Min 3
Diffuse: 4
Glossy: 4
Transmission: 12
Volume: 1

Is there a way to optimize things?

$\endgroup$
  • 3
    $\begingroup$ Are you reading the 5% cpu when it is rendering, or just starting, during the Building BVH? $\endgroup$ – David Sep 28 '14 at 17:08
  • $\begingroup$ After building bvh, when the image is rendering the task manager says: 5% cpu usage. In the last 20 hours cycles has rendered 269 of 26311 tiles at 4-6%. $\endgroup$ – p2or Sep 28 '14 at 17:13
  • $\begingroup$ Odd.. I tried this too, rendering the default cube at 27000x7000 my cpu stayed around ~50% (waffling around a bit). At 2700x700, my cpu was glued to 100%. $\endgroup$ – gandalf3 Sep 28 '14 at 18:39
  • 1
    $\begingroup$ Commandline rendering seems to work (100% cpu usage at the moment). $\endgroup$ – p2or Sep 28 '14 at 19:01
14
$\begingroup$

With very large image resolutions Blender can run out of RAM. The operating system will then start using the hard disk for memory which is slow and will cause low CPU usage (swapping).

To reduce memory usage for very high resolution renders:

  • Enable Save Buffers in the Performance panel so Blender does not keep the full render in memory during render
  • Render from the command line so no display buffer must be kept in memory
  • Output to an OpenEXR file so one tile can be written at a time
$\endgroup$
  • $\begingroup$ In my test I still had over half my ram free.. Blender used 1.5GB out of 15.7GB total. CPU usage was at 100% while building BVH and preparing, but dropped to about 20% once rendering started and stayed between 20% and 50% for about a minute, at which point I stopped it. Rendering from the CLI worked fine. $\endgroup$ – gandalf3 Sep 29 '14 at 1:02
  • $\begingroup$ I also have swap disabled. $\endgroup$ – gandalf3 Sep 29 '14 at 1:09
  • 3
    $\begingroup$ Displaying a very large image is probably a bottleneck too, which could be avoided by hiding the image editor that is showing the render result. In any case, the command line will have the least memory and CPU overhead. $\endgroup$ – brecht Sep 29 '14 at 1:20
  • $\begingroup$ Makes sense.. Though I still don't see why drawing the huge image would cause less CPU usage.. Wouldn't the CPU still chug along as fast as it can, just put not quite as much effort on path tracing and slightly more effort on (communicating with the GPU?) to draw the image? $\endgroup$ – gandalf3 Sep 29 '14 at 1:23
  • 3
    $\begingroup$ Ideally yes, but threads may need to wait writing to the render buffer while the display thread is drawing it. $\endgroup$ – brecht Sep 29 '14 at 1:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.