Enable intel's tiled denoising mode for OIDN, to allow users to denoise high res images
Blender's OIDN denoiser in the compositor and the one from the render panel can be MASSIVELY improved with virtually no work from the developers (just a few properties need setting)
There's a feature of Intel's open image denoiser (used by blender), that denoises in small tiles instead of the whole image at once. This means no matter how pants your computer is, you should be able to denoise very high resolution renders without Blender freezing or crashing.
As far as I know it's just one property called --maxmem . The Blender dev's need to dynamically set this based on the users available system memory, and it automatically denoises in small tiles that won't exceed that.
In Luxrender they've turned it on and not only does it allow people to succesfuly denoise large resolution images, but it also does it much faster in some instances. Here's an excerpt from their forum (full thread here: forums.luxcorerender.org/viewtopic.php ) :
code:
github.com/CodeFHD/LuxCore/blob/master/src/slg/film/imagepipeline/plugins/intel_oidn.cpp
github.com/CodeFHD/LuxCore/blob/master/include/slg/film/imagepipeline/plugins/intel_oidn.h
github.com/CodeFHD/LuxCore/blob/master/src/slg/film/filmparse.cpp
I have included another keyword for testing. If you set film.imagepipelines.[...].oidnbench = 1 in the render.cfg, it will first execute the tiled and then the single OIDN. This makes it easier to compare performance for large renders without having to re-render everything. I also added timing counters over the entire function, not only each filter execution to include the buffer-writing and overlap computation.
Two quick performance meaurements on the LuxMark-Hotel scene:
At 3840x2160 (not exceeding my RAM): tiled OIDN 7.5s, single OIDN 5.5s. For comparison, the render-time to 20 Samples was 270s on an i5-9600K (0.7% penalty) At 7680x4320 (exceeding my RAM): tiled OIDN 26s, single OIDN 74s. For comparison, the render-time to 20 Samples was 1185s on an i5-9600K (4% gain)
8 Comments
For anyone wanting to pick this up, you can peek at an attempt I made some time ago: archive.blender.org/developer/D7758
I didn't follow up on it though. It only changed the Compositor and added a user-preference. Setting this parameter is trivial - once you have a good value to set it to and plumb that through to the place to actually set it.
Nowadays the OIDN viewport/final-render piece is missing, as was investigation into what a good default should be: maybe 50% of memory as suggested in the above link.
That's awesome! Can you imagine the elation of the many people stuck with 16 GB of ram or less, to finally be able to render higher than 1080p renders! I have 32GB and even that struggles over 4k.
Just for the compositor would be fine, certainly better than nothing.
Yeah, I think 50% would be safe. Maybe a bit higher for lower resolution images? I believe it defaults to 3000MB at the moment. I'm unsure why they wouldn't have just based it on available ram rather than a fixed value.
Although, if a user has 64GB or RAM, limiting them to 32GB might not be the best idea?
Perhaps it should be:
The 2GB for the os.
I'm not sure if maxMemoryMB should be used instead. The changelog says:
maxMemoryMB filter parameter for limiting the maximum memory consumption regardless of the image resolution, potentially at the cost of lower denoising speed. This is internally implemented by denoising the image in tiles.
Right, the
maxMemoryMBsetting is what my patch used and it's what LuxCore is using as well. The default value is 6000 mb. So this is what Blender is using today because it's the OIDN default. It's also the default for LuxCore's setting as well.Toying around with the exact value to set this too is why I didn't follow up on the patch. Defaulting to 50% means that any device with more than 12gb of system memory will be using more memory for OIDN than it does today. Which would seem counter to the goal.
I think they changed it to 3000MB in OIDN 1 .4 .
I don't think it's a problem if more than 6000MB is specified, the only problem is if that amount of memory isn't available. OIDN will already automatically split the image into the number of tiles necessary to ensure each tile doesn't need more than that amount of RAM.
The problem that's happening at the moment, is when people have less than 3000MB, it breaks. Presumably because OIDN is breaking the image into tiles of maxMemoryMB, regardless of whether it's available? If this is true, and is set to 6000MB by Blender currently, then this will make problems much more likely for users with 8GB - 16GB of ram. I even had one guy who had 128GB or RAM run into problems, because his scene was using so much RAM that he had less than --maxmem available for denoising.
The amount of RAM needs to dynamically specified at the beginning of the denoising process, so that persistent data etc are accounted for of course (not just an automatically calculated property in the preferences set to 50% of physical RAM). I'm sure I'm preaching to the choir though :D
Ah, it does look like they updated the default to 3000. In any case Blender is not setting the value today, so 3000 is what is being used (this is what I meant by my previous statement; Blender just uses whatever OIDN does right now).
ah OK, that would explain why the dreaded entirely black denoised image issue became less frequent down after 1.4.