Memory Metric (Python Plugin)

[sapo17]

Hi!

First of all, once again, thanks for this wonderful tool and your great work.

I have a custom BSDF (Mitsuba 3: Tutorial Custom Plugin) and use the Python plugin. I have a test scene (Mitsuba 3: Gallery Material preview) that I usually render with the cuda_ad_rgb variant using my custom BSDF.

Question: I would like to know how much memory my custom BSDF uses in comparison to a reference (e.g., a Mitsuba BSDF). Is there a suggested / general* way of doing this?

For instance, DrJit offers drjit.kernel_history() for performance benchmarks, which I absolutely adore.

Disclaimer: When it comes to memory-related stuff, I am completely ignorant (e.g., which metric to use, what to consider, etc.). As such, I would be extremely happy for any type of suggestions (e.g., relevant papers, code snippets, etc.).

Let me know if you need additional information from my side. And, thank you very much in advance!

Kind regards,
Can

*General in the sense that it gives meaningful metrics for the given mitsuba variant (e.g., cuda_ad_rgb).

[wjakob]

Mitsuba/Dr.Jit will by default compile your custom BRDF into a subroutine of a Megakernel. This means that temporary steps of the computation are stored in registers and won't take up any memory. The only memory usage is in terms of textures etc., that drive the parameters of your model.

[sapo17]

Thank you for the quick clarification! A follow-up, if I may:

The only memory usage is in terms of textures etc

Is this also the case, for example, with the data-driven material model? That is, in a data-driven model, the only memory usage is in terms of the "reflectance data" (e.g., measured VNDFs)?

Mitsuba/Dr.Jit will by default compile your custom BRDF into a subroutine of a Megakernel...

What happens if the following flags are set? In particular, before I render, I usually turn off the megakernel* due to intricacies in my implementation:

(Older Mitsuba versions)

dr.set_flag(dr.JitFlag.VCallRecord, False)
dr.set_flag(dr.JitFlag.LoopRecord, False)

(Newer versions)

dr.set_flag(dr.JitFlag.SymbolicCalls, False)

PS: Sorry for the headache, and thanks in advance.

---

*mentioned in #586, #812

[wjakob]

Is this also the case, for example, with the [data-driven material model (https://mitsuba.readthedocs.io/en/stable/src/generated/plugins_bsdfs.html#measured-material-measured)? That is, in a data-driven model, the only memory usage is in terms of the "reflectance data" (e.g., measured VNDFs)?

It's best to think of the data of this model as an input texture that the model gets to query at a few places. The model evaluation itself is kept in registers.

What happens if the following flags are set?

Uh.. this will dramatically slow down rendering and is a terrible idea except for debugging. Memory usage will then be proportional to (#samples in flight) * (#number of arguments passed to BRDF). The internal computation of the BRDF will still stay in registers, Dr.Jit fuses such steps.

Could you explain what you are trying to accomplish/prove? Then we can perhaps give more useful advice.

[sapo17]

Hmm... I see. Thank you for the feedback. It's best I avoid disabling the megakernel.

TL;DR: Essentially, I think I need to revisit my implementation to ensure that I do not disable megakernel. Then, based on that, I can make a better comparison in terms of memory usage and performance.

Could you explain what you are trying to accomplish/prove? Then we can perhaps give more useful advice.

I would be happy to, but unfortunately, it is too involved. In essence, I am comparing a reference mitsuba BRDF (e.g., Measured BSDF, but not only) vs. a custom BRDF:

• In terms of performance, I did this by turning off the megakernel and using dr.kernel_history(). Apparently, disabling the megakernel is not so smart.
• I also want to compare how much the memory consumption is.

I am disabling the megakernel because I have to access some rows (coefficients) of a mi.TensorXf inside a symbolic loop. I then use these coefficients to sample and evaluate distributions. I (poorly) expressed the idea quite abstractly here. So far, I am unable to do this without disabling the megakernel. I will have to revisit my implementation.

[wjakob]

Gathering into a tensor from a symbolic region should be fine. The Mitsuba measured BRDF does basically this. Same thing with the envmap light source, it samples a row and then a column from a 2D image using bisection search on a precomputed 2D CDF.

[sapo17]

Thank you very much, I really appreciate the feedback. I've made some crucial progress.

The original version of this message contained another detailed question regarding accessing and symbolic variables. I deleted it after figuring out a version that worked for me. My overall tip to others: At all costs, avoid/delay creating symbolic variables that you know you will need to access in subsequent steps.