pmj02bn skipping precomputed sets? about pbrt-v4 HOT 3 CLOSED

Good eye--you are correct about all of that. That is actually intended, though a little ugly / unsatisfying. Here's the story...

Samplers must provide a StartPixelSample() method, which takes a pixel, a sample index, and the dimension of the sample vector to start at. Further, they're supposed to be deterministic about the samples that they generate (new in pbrt-v4, but a real help for debugging, since you can re-render a single pixel and know the same computations will happen for it as for the entire image.)

Now, in the GPU path, Samplers aren't persistent, like they are in the CPU renderer. Rather, Samplers are allocated on the stack in kernels that need them, which is currently a) the camera ray generation kernel, and b) the kernel that generates the samples that will be needed for the next path vertex. So the camera ray kernel starts at dimension 0 as usual, but then the other kernel has to figure out which dimension to start at for each bounce.

Ok, so on to the pmj sampler. On the CPU, we could maintain a separate index into the pmj tables and only increment it when a 2D sample was taken. On the GPU, we sort of don't know how many PMJ dimensions have been consumed when we start at an arbitrary sample dimension. Hence, the way it's implemented. Although that skips over pmj sample table entries, it is deterministic for a given dimension, and at least it never reuses the same table twice in a row...

(Maybe there is a cleaner solution. That is all admittedly a little hacky, but I don't have a better idea...)

from pbrt-v4.

Oh that's interesting, I hadn't dug into the GPU implementation much beyond your HPG talk and YouTube video. Thank you for the explanation!

I'm probably missing something, but could you change it to pmjInstance = dimension/2, while still incrementing by 2? I think that would be deterministic for a given dimension, and it would skip fewer sample sets, although it would still skip one for every 2 Get1D() calls.

from pbrt-v4.

Yep, you're right--good point. Fixed now--thanks!

from pbrt-v4.