Page MenuHome

Number of samples taken per progressive iteration
Needs RevisionPublic

Authored by Lukas Stockner (lukasstockner97) on Feb 9 2014, 4:12 PM.

Details

Summary

This patch basically adds a compromise between tiled and progressive rendering: An option to choose how many samples are taken in every Tile in progressive mode (currently, this is hard-coded to 1). This is a compromise between the rapid feedback of progressive mode and the better cache access of tiled mode (at least I think the benefit of Tiles is the cache).
In a test with the Lego bulldozer from BlendSwap (http://www.blendswap.com/blends/view/72124) with a reduced resolution, 500 samples, 8 threads and 64x64 tiles, tiled mode took 2:58.39, standard progressive took 3:31.34 and progressive with 25 samples/iteration took 3:09.05.
Also, this makes it possible to add adaptive sampling later: After every progressive iteration, a new noise map could be generated, which is used again for the next iteration. With only 1 sample/iteration, the overhead would probably be way to high.

Diff Detail

Event Timeline

Brecht Van Lommel (brecht) requested changes to this revision.Feb 10 2014, 2:45 PM

Can we do this more automatic somehow?

We could for example double the number of progressive samples each time until it's at e.g. 24. That way you get quick feedback in the beginning but still get the performance benefit for the rest of the render. Due to the way monte carlo integration works the image changes more slowly the more samples you take anyway.

intern/cycles/render/tile.cpp
272–278

This should be clamped by the total number of samples, so the last step should take fewer samples if the total number is not divisible by this.

Lukas Stockner (lukasstockner97) updated this revision to Unknown Object (????).Feb 14 2014, 5:16 PM

Now the sampling steps always double per iteration from 1 to the user input, where they remain until they are clipped to the maximum sample number.

I am not a real fan of adding more UI options for such kind of features. The performance panel is already quite big. I think it's reasonable to do that automatically and update every 10-20 samples.

Brecht Van Lommel (brecht) requested changes to this revision.Mar 7 2014, 3:32 PM

I agree, we can hide this from the user.

I also don't think we should double every time, only until some limit like e.g. 16 samples. If you've got 512 samples you don't want to wait until it's at 1024 to see some update.

Although Indigo for example does the always-doubling, I found it to be really annoying, so I agree with you. Indeed, this is what the patch already does.
Regarding UI: Yes, hiding the option might be reasonable since AFAIK it could still be changed in the Scene in Outliner.

Ah, I misunderstood the way this patch worked.

I think the option should be renamed to something that better indicates what it does, like "max_samples_per_update" (not really happy with that either, maybe you can think of something better), and the description can be extended to better explain it. The default value can be set to something like 16, 24, 32, .. not sure what works well.

I still don't like to expose this, Progressive Refine is already not a very commonly used feature afaik, it should be reasonable to use the doubling until we reach a sample number (16, 32, something like that) and then just update every 20-30 samples or so. If you want highest performance you should use Tiles anway.

Lukas Stockner (lukasstockner97) edited edge metadata.

After a long time, here is an updated version of this patch. No real changes in functionality.

Sergey Sharybin (sergey) requested changes to this revision.Dec 3 2014, 6:32 PM

I'd go with something like max(4, sqrt(current_sample)) (maybe multiple sqrt by some constant like 0.5 or so as well). Play around with this, should be easy to find curve which would work best without any manual configuration.

This revision now requires changes to proceed.Dec 3 2014, 6:32 PM

Hi, being a former Maxwell user I can say how much progressive refine can be useful, giving you the chance to stop the process anytime and have a full-frame render anyway. The plus in Maxwell is that for each step it actually writes a temp image, to keep the job safe in case of a crash or power failure.