Page MenuHome

Allow the OIDN maxMemoryMB setting to be set in system preferences
AbandonedPublic

Authored by Jesse Yurkovich (deadpin) on May 17 2020, 7:44 AM.

Details

Reviewers
Brecht Van Lommel (brecht)
Group Reviewers
VFX & Video
Summary

In an attempt to address issues like T76790, this exposes OIDN's maxMemoryMB setting as a system user preference.
It adds a new Compositor section, collapsed by default, to the System page but I'm open for better placement elsewhere if desired especially if such a limit would be used along with T76259.

By default blender will use the same value that OIDN currently ships with: 6000

For a 3 frame, 7680 × 4320 (8k) render, the following was observed for the denoising performance (in seconds):

Using 6000mb (baseline)
time end (execute): 26.141918
time end (execute): 25.793146
time end (execute): 26.283325

Using 1024mb
time end (execute): 42.992428
time end (execute): 46.625431
time end (execute): 41.559349

Using 12000mb
time end (execute): 26.967207
time end (execute): 25.856495
time end (execute): 25.136459

Diff Detail

Repository
rB Blender
Branch
oidnmemory (branched from master)
Build Status
Buildable 8082
Build 8082: arc lint + arc unit

Event Timeline

Jesse Yurkovich (deadpin) requested review of this revision.May 17 2020, 7:44 AM

How does it work when there are multiple OIDN denoise nodes running in parallel?

If we go this route it should be more generic limit, not specific to compositor (as you've mentioned, OIDN will be used in Cycles as well).

@Brecht Van Lommel (brecht), not sure we should be going this route. There are cons and pros. Surely, in more ideal world we would have global limit for compositor (so it stops adding memory buffers that aggressively), but that's quite a big project. Shall we expose this setting "for now"? Shall we pick up some decent mid-range limit, so Blender fits in memory without too much speed loss?

Brecht Van Lommel (brecht) requested changes to this revision.Jun 30 2020, 11:48 AM

I don't think this should be an option, instead it can be set to for example 50% of system memory.

There is already a mutex lock to ensure only one denoise node executes at a time.

This revision now requires changes to proceed.Jun 30 2020, 11:48 AM

Will abandon for now since the design should change to not have the memory limit exposed as desired from feedback above. I'll also have to take a look at the OIDN viewport support to see if it needs to be adjusted similarly.