Adaptative sampling

[anthebault]

Hello,

I am currently working on an adaptative sampling method to import pre-generated sampling maps in Mitsuba and enclose the render jobs through those values. I already added a new AOV for the spps but i foresee some problematic steps :

• Sampler is studied to carry one sampling value, especially with a spp per pass limitation on GPUs, and is a core element in the rendering loop
• Adaptative sampling implies non uniform distribution of computation amongst blocks, as some may carry drastically more spps than other.
• Other technical implications (sampling map importation with XML properties, base CPU/GPU/LLVM loops to rework, etc.)

I mostly studied the C++ code, but are there other function / locks I should know about ? I noticed a newly added section in DrJIT's docs (https://drjit.readthedocs.io/en/latest/reference.html#drjit.switch) that could be useful when differentiating Sampler instances.

Best regards,

[njroussel]

Hi @anthebault

I feel like you have a good grasp on the main components involved.

I don't believe you'll be able to merge the non-JIT (scalar-* variants) render pipeline with the JIT one. There already is a strong separation (see integrator.cpp), and I don't think you'll be able to have a single implementation that fits both cases. There is a Python counterpart to all of this logic in src/python/ad/integrators/common.py.

[anthebault]

Thank you for your response @njroussel .
For now, I have a working setup for CPU/non-JIT variants

I'll be looking for the ad integrator. The Sampler Structure is a main issue (especially ldsamplers with square checks) as the indices are computed from the global wavefront size and the generic number of spp, messing with the patterns and generating occasional segfaults.
Is there also a "good way" to spread precise texture data on each kernel (I use a derived texture plugin to retrieve sampling data from an exr file) ? The SPPs are currently passed within a tensor or by directly accessing the bitmap data through pointers but there may be more elegant solutions with the DrJIT library.
Best regards,

[njroussel]

The SPPs are currently passed within a tensor or by directly accessing the bitmap data through pointers but there may be more elegant solutions with the DrJIT library.

I would implemented this like that too, nothing better comes to mind.

[anthebault]

It is a quite challenging experience and some adaptations/fixes are still required, but we are getting somewhere (rendered with the CUDA JIT variant). The texture computes an offset map to ponderate the "pos" Array, coupled with scatters.

This sampling map uses less spps compared to the previous one