Page MenuHome

Render: Add option to write frames asynchronously when rendering animations
Needs ReviewPublic

Authored by Lukas Stockner (lukasstockner97) on Sun, Jun 7, 8:19 PM.

Details

Summary

Currently, when rendering an animation, Blender first renders a frame, then
writes it to disk, and then continues with the next frame.

In some cases, this can introduce a considerable slowdown:

  • When using Eevee
  • When rendering very simple scenes with Cycles
  • When using high compression settings
  • When using slow storage (e.g. writing huge EXRs to a network share)

Since the frame writing is mostly singlethreaded and doesn't depend on scene
state, it can be executed in the background while the next frame is already
being rendered.
The current code is designed to only use one background thread, meaning that
it waits for frame N to be written before it writes frame N+1.
Using a deeper queue could provide even more speedup if rendering is faster
than saving, but that's probably fairly rare and not possible with movie
output, so the single thread is easier to implement for now.

The three downsides of this currently are:

  • A copy of the old Render Result has to be kept in memory, increasing RAM usage.
  • Console messages about the frame writing are mixed into the usual rendering logging.
  • It's unclear how to properly handle the render_write callback.

For these reasons and because it's hard to test all the special cases, the option is
currently controlled by a User Preference that defaults to off (similar to other
options that have an impact on RAM usage). In the future, we could turn this on by
default.

Diff Detail

Repository
rB Blender
Branch
parallel-render-save (branched from master)
Build Status
Buildable 8421
Build 8421: arc lint + arc unit

Event Timeline

Lukas Stockner (lukasstockner97) requested review of this revision.Sun, Jun 7, 8:19 PM
Lukas Stockner (lukasstockner97) created this revision.

That's a very interesting feature.

What was the scene and setup you've been testing this with? What was the gained speedup?
Such information should come together with technical side of presentation of your code work.

What was the gained speedup?

@Sergey Sharybin (sergey) Here's a few tests I ran to show the performance difference:

Specifications:
Ryzen 9 3900X locked at 3.9Ghz.
32GB of 3200Mhz RAM
On Linux-5.4.0-7634-generic-x86_64-with-debian-bullseye
All frames were saved to a USB 3.0 HDD

The first test I ran was rendering an animation from the 2.82 splash screen.

Render engine:EEVEE
Frames rendered:100-200 (101)
Samples:4
Resolution:3840x2160
File format:PNG
Extras:RGB, 25% compression
Average frame size:18MB

The times listed below are in seconds and are for the time of rendering + compositing + saving of all 101 frames in the animation.

Tests were run in the order Standard -> A-Sync -> Standard -> A-sync to avoid any issues that disk fragmentation may cause.

Standard image savingA-Sync image savingTime saved
Run 149340588
Run 248940584
Run 349240488
Average491.3404.686.6

With this scene, on average 0.86 seconds of processing time is saved per frame. With a 10 minute long animation at 24fps (total of 14,400 frames), the total time saved using this patch is 12,384 seconds. Or better put, 3 hours 26 minutes and 24 seconds.


The second test I ran was with my computer animation scene. However I applied a lot of the modifiers before hand to speed up Cycles pre-load times.

Render engine:Cycles (CPU rendering)
Frames rendered:100-130 (31)
Samples:32
Resolution:3840x2160
File format:Multi-layer Open-EXR
Layers saved:Combined, Depth, Mist, Normals, Denoising data, AO
Extras:RGBA, Float (Full), Zip (Lossless)
Average frame size:468MB

Once again, times are listed in seconds and cover the entire time of rendering + saving for all 31 frames.

Standard image savingA-Sync image savingTime saved
Run 11,8261,78640

Only ran one test as I'm confident the results will be similar between three separate runs based on the results from the previous test.

With this test, we save 1.3 seconds per frame. My original animation is around 3000 frames long. So if I had this feature back then, I could of saved a total of 3,900 seconds. Or better put 1 hour and 5 minutes.

Obviously, as you use greater compression ratios, or save larger files, or save to slower storage, the patch will offer a better speed up (assuming other factors don't influence the scene too much).


What about memory usage? I was unable to accurately measure this due to what I believe is a bug. Will investigate it further and make a bug report if it is indeed a bug. T78149