How to properly set up multipass for high SPP

[Disgruntoad]

Hi all,

I was trying to reduce noise in a custom rendering based on the banner_02 asset (https://mitsuba.readthedocs.io/en/stable/src/gallery.html), and to do so I needed to increase the number of samples per pixel to reduce noise. I ran into the error pictured above (reproduced with the original scene.xml file for reproducibility).

I'm not quite sure what is going wrong. For reference, my system has 64gb ram and 24gb vram. With spp=2048, my system uses under 15gb ram and 2gb vram to render. I assume I'm making a relatively simple mistake, but a google // mitsuba doc search didn't reveal anything. Any help would be appreciated.

I understand that the error is an attempt to allocate 34gb vram, but the render doesn't use more than 2gb vram at any point.

[merlinND]

Hello @Disgruntoad,

Have you tried giving a smaller samples_per_pass value to the integrator?

There's a warning indicating that it's deprecated:

mitsuba3/src/render/integrator.cpp

Lines 109 to 115 in 29d6537

	m_samples_per_pass = props.get<uint32_t>("samples_per_pass", (uint32_t) -1);
	if (m_samples_per_pass != (uint32_t) -1) {
	Log(Warn, "The 'samples_per_pass' is deprecated, as a poor choice of "
	"this parameter can have a detrimental effect on performance. "
	"Please leave it undefined; Mitsuba will then automatically "
	"choose the necessary number of passes.");
	}

But I'm not familiar with the new solution, so it's maybe still worth trying.

[merlinND]

I'm glad it worked!
I don't think it's the intended solution though, maybe @njroussel or @Speierers know how the automatic batching is supposed to work?

[njroussel]

It should "just work ™️". The idea is that it would figure out how to chop up the total number of samples, given that OptiX has a maxmium number of samples it can handle per kernel.

In any case, the memory usage should not increase. I'll have a look.

[njroussel]

Had a quick look at it this morning. It's a bit unfortunate but we need to evaluate and store the sampler's state between each pass, just in case it's some stratified sampler. That state can be surprisingly large, for example in an independent sampler it's represented by two 8 byte values per lane/thread:
2 * 8 * (2 ** 31 - 1) ~= 68 GB
I the case of @Disgruntoad 's example this makes sense: one of the two values would require 34 GB.

We should maybe have a special code path for the independent sampler as it really doesn't need to store its state between passes.

[Disgruntoad]

@njroussel

Thanks for the explanation! I'm a little confused though -- could you break down the math for me? I assume it's
2 values
8 bytes
2**31 - 1 lanes?

What are the lane/threads and how did you arrive at 2**31-1?

Pretty new here, want to start building up some knowledge. Thanks!

[njroussel]

Yes, that breakdown is correct.

The 2**31 - 1 is the kernel width / launch size - it defines the number of threads/elements that needs to be computed. It's a hardware limit, we can't go above that. Of course, in many cases we're well below that value. However, for high-spp&high-res renderings that limit can be hit quickly and then the image gets rendered in multiple passes (multiple kernels of 2**32-1 each).