SPPM implementation in mitsuba3

[arpit15]

I implemented SPPM integrator in mitsuba3 based on pbrt-v4 cpu integrators. The implementation is available here.
I tested the code on cornell box scene and my custom own scene. Everything seems to be fine and as aspected if the image height and width is a power of 2. I show the resulting image below for cornell box scene.

However, I observe weird blocky artifacts if I change the height/width to not be a power of two, eg. 500x512. Following image is obtained.

I am able to get rid of this bug by uncommenting a very innocuous line. Everything seems to work after this.
Also, this behavior is not observed if I compile the code in debug mode. I have tried various debugging tricks. In all the cases, the code seems to work if I have a Log statement and a reference to any one/all of the loop counters. If I replace the print statement with cout or remove reference to loop counters, the bad behavior reappears.

Update 1
I tested compile optimization flags for my example with magical Log line commented out

1. -O2 and -O3 give same bad result
2. -O1 correct image is produced

Any help to debug this weird bug is much appreciated. Please let me know if you have any suggestions.

Update 2
The bug was in hash function calculation. I copied it from here without much due diligence.
After updating the hash function to following

template <typename Float>
inline size_t Hash(const Point<dr::int32_array_t<Float>, 3> &p)
{
    // return ((p.x() * 73856093) ^ (p.y() * 19349663) ^ (p.z() * 83492791));
    std::vector<int> v = {p.x(), p.y(), p.z()};
    return hash(v);
}

I am able to obtain following image with cbox with 16 spp. This one seems to have blocky artifact as well. But they seem to go away.

I am wondering if there is a preferred hash function for sppm algorithms.

[Microno95]

While I'm not sure what the exact cause is, it may be caused by the fact that attempting to log the loop variable leads to an evaluation of some Dr.JIT variable.

What variant is the problem occurring with; scalar or cuda/llvm variants?

[merlinND]

Since the variable being printed (xx) is a plain int, it shouldn't trigger an eval of DrJit variables. However it could affect the timing of some asynchronous computation, which would point to a race condition / synchronization bug?

[arpit15]

While I'm not sure what the exact cause is, it may be caused by the fact that attempting to log the loop variable leads to an evaluation of some Dr.JIT variable.

What variant is the problem occurring with; scalar or cuda/llvm variants?

The bug is in scalar_rgb mode. I have only implementation for that mode.

[arpit15]

@merlinND I am using thread-safe heap allocator from PBRT for creating photon map. My guess is that it might be causing issues. I am wondering if you have a better suggestion. I couldn't adapt mitsuba3 kdtree OrderedChunkAllocator for my use-case.

I checked part I: visible points shooting. I am able to match the result of direct contributions. According to me, this makes my first part to be correct.
I can't think of simple ways to check the 2nd (photon map creation) and 3rd (photon shooting).

[njroussel]

Very cool and impressive!

As for the bug, the first thing that comes to mind is that you're not initializing some JIT variable. For example, anything like this:

Float a;
BoundingBox3f bbox;

Should absolutely always be written as:

Float a = dr::zeros<Float>();
BoundingBox3fbox = dr::zeros<BoundingBox3f>();

(or some other valid constructor).

The magic and harmless log is just luckily shifting whatever your uninitialized memory is pointing at to something "correct". Debug mode tends to aggressively zero-initialize C++ members, which might help too.
To be clear, this is just a guess from loads of similar bugs&artefacts we've encountered.

[arpit15]

Thanks for the suggestion. I didn't get any notification for discussion.
I will update with all the zero initialization for JIT vars and check if the problem persists.

[arpit15]

I have updated the code with all the JIT vars to zero init apart from BSDFContext. I also did some testing on my linux machine.
The problem seems to be specific to Mac. I am not seeing issues on my linux system.
I also tested with clang 17.0.1. But embree causes some compile issues, which I didn't resolve.
For Mac my system details are as follows

MacOS version: Sonoma 14.4.1 (23E224)
Compiler: Homebrew clang 15.0.0 arm64-apple-darwin23.4.0 
Drjit version: v0.4.4 9aa2d87a98be303368f991581ad5297782cba85a

Can you kindly let me know if there are other suggestions to test?

Also, is there any plan to merge photon-mapping algos into mitsuba3?

[arpit15]

@njroussel I also notice the issue if compile mitsuba in release mode, render using python, and set the logger level to Info instead of Debug. However, the same scene renders fine with mitsuba exe with default args.
In both cases, the code was compiled with print statement switched on macOS.

[inversetrs]

I believe they would receptive to a pull request, I previously talked about it and @Speierers seemed open to the idea: #181 (comment)

I'll be happy to test your implementation on a couple of scenes.

[arpit15]

Sorry for a late reply. I will link the implementation today for you to test.