Viewport Denoise Sample Step vs Start Sample
Denoise Sample Step would decrease viewport render times by 80% when using OpenImageDenoise and 30% when using OptiX while also enhancing the user experience. Denoise Sample Step would significantly reduce the compute resources required to incorporate denoising in the viewport making OpenImageDenoise performance nearly identical when using OptiX by reducing the workload.
I created a video explaining the problem that this solves. youtu.be/4SphW9TWLFQ
Enabling the denoiser in the viewport currently consumes a massive amount of compute resources when using OpenImageDenoise. This feature would increase the viewport rendering efficiency by 650% while providing the user immediate denoised results.
Currently a user can set the "Start Sample" to determine which sample to begin denoising but this option gives a poor experience to the user unable to see immediate results, and also consumes a massive amount of compute resources on each sample after the "start sample number", unnecessarily slowing down the render time.
This feature "Denoise Sample Step" would denoise the first rendered sample to give the user an instantly denoised image, but skip denoising samples until reaching the subsequent "step" (Only denoise the image and update viewport when SampleNumber % Step == 0).
For example, if the viewport Max Samples is set to 256 and the new option called "Denoise Sample Step" is set to 16 the viewport image would only denoise and update 16 times at samples 1, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, 256, including of course the last frame if it does not fall on the step factor.
Without this setting OpenImageDenoise would have executed 256 times instead of only 16 times. In my tests there was an 650% increase in performance which is an 86% decrease in render times along with a 87% reduction in CPU utilization (Less Power and Heat).
4 Comments
I was thinking about this again today. A Simple interim workaround could be to change the code in the "Start Sample" to check if there are any numbers separated by commas vs a single integer. If there are multiple numbers separated by commas than put the numbers into a list (array) and only do the denoise on the 1st sample, the samples numbers in the list, and the last sample. Otherwise if there is a single integer in the "start sample" field then do the denoise on each sample after the "start sample". Obviously this is a bit of a "hack" but could be a quick thing to implement without changing much of anything in the code.
Maybe another solution is to make step size automatic / use same value as start sample? If you start step is 4 then denoising will happen at 4, 8, 12... That way there is no extra setting to fiddle.
Still, root of issue is more about oid being slow and cpu only. Gpu oid support is being worked on 108314 .
Even though GPU denoising is being worked on, if you watch the video I made denoising with GPU based OptiX is still 30% slower and I believe it's because it's doing the denoising after every sample which is completely unnecessary. The GPU on that scene is able to do 256 samples in 7 seconds without OptiX enabled, with OptiX enabled it takes about 10 seconds. Sure it's really fast for my Nvidia RTX 4090, but not everybody has a card this powerful, 30% slower is significant.
My point is that even when using GPU rendering it will be significantly beneficial to not denoise and after every render sample. Implimenting a "Sample Step" would provide the ability to still provide the desired feedback to the user while being as efficient with processing in both CPU and GPU as desired by the user.
I do like the idea of having "Start Sample" basically act as a "step" factor. If the Max samples is set to 256 and the "start sample" is set to 64 it would automatically denoise at sample 1, 64, 128, 192, and 256 (and of course when completed if it doesn't fall on a step factor). That would make a lot of sense.
Rename "Start Sample" to "Sample Step"