Debugging pattern for BSDF plugin

[leroyvn]

I'm working on a C++ BSDF plugin. My unit tests pass, both with scalar and LLVM variants. The rendering output I get with scalar variants is correct; it is different−and incorrect−when I use LLVM variants.

The most straightforward way to debug this with scalar variants would be to simply add some logging output in the code and inspect variables during execution, but I can't do this with JIT-compiled variants. Is there an appropriate workflow you can recommend in such situation?

[wjakob]

What I would suggest is to implement a chi^2 test first, as is done in many other BSDF plugins. Next, you can spot-check the value of the BSDF and result of the sampling algorithm for specific input arguments and compare variants. If discrepancies emerge, you can std::cout variables within the implementation. The important thing is not to try to debug something like this within a rendering algorithm.

[leroyvn]

I did that indeed, and oddly the test passes, which is even more confusing. I only see differences when I render a scene.

[wjakob]

Can you divide+conquer by commeting out/setting things to zero to reduce the inconsistent part to a specific region of your model's code. To run comparisons between two backends, the model doesn't necessarily need to make physical sense.

[leroyvn]

Thanks a lot @wjakob, this finally helped me track the nasty line which broke everything. The following line was missing from the constructor:

dr::set_attr(this, "flags", m_flags);

[wjakob]

ugh. We keep running into this over and over again. Perhaps we should think of some kind of default initialization that raises an exception in debug mode (CC @njroussel)

[wjakob]

Another option could be an alternative version of the DRJIT_VCALL interface that calls every getter (without developers having to manually calling dr:set_attr) builds a table, and uploads it to the GPU.