Python API and shapegroup instances efficiency

[devel4848]

I did some experiments with shapegroup instances with Mitsuba 3 Python API. I rendered the same scene with two different representations. The scene is a forest made of identical trees. One tree is made of a trunc and a lot of identical leaves.

In the first representation I used few instances of a few big meshes : one mesh for the trunc, one big mesh for the whole leaves. Each tree is made of one instance of the trunc and one instance of the whole-foliage-single-mesh.

In the second representation I used a lot of instances of small meshes : one mesh for the trunc, one small mesh for each leaf. Each tree is made of one instance of the trunc and ~9000 instances of the one-leaf-mesh.

In the two representations I loaded the meshes only once and created one shapegroup per mesh.

I measured the RAM used to load and render the scene. I noticed that the 2nd representation (lot of instances of small meshes) used a huge amount of RAM compared to the 1st representation (few instances of big meshes). For example 100 trees with the 2nd representation used 4.4GB of RAM, whereas ~60000 trees with the 1st representation used 2.8GB of RAM.

I'm surprised how costly instances are with RAM usage. Is it the expected result or is it a sign that there is something wrong with my implementation?

[njroussel]

Hi @devel4848

Are you using the CUDA or LLVM backend?

This is something we don't really implement ourselves, we rely on Optix/Embree to handle the acceleration structure and instancing for us. Maybe we're misusing their API.

To be honest, I don't think we've made use of the instancing feature recently (or ever) ourselves. So, I don't have any expectations and our code might have a bug. Intuitively, I agree with you, I find your results surprising.

[devel4848]

Hello @njroussel. I used the scalar_rgb variant.

[leroyvn]

I observed this behaviour in a similar situation (mesh-based trees, a couple of thousand instances, scalar variant).

[njroussel]

Interesting. Just by taking a quick look at the code, nothing obvious jumps to mind. I'll add that to the stack of things to look into eventually.

@devel4848 I doubt you're doing something wrong. If you dig further and can pinpoint some dubious memory allocations, I'll gladly jump in to help to provide a fix.

[gnauk]

Hi，@njroussel
I used the cuda backend. The scene is one shapegroup(700k facets) and mutiple instances(for example,100,500,1000 times). The JIT compile time increase the similar times along with the instance numbers increase. Is this normal behavior？Have methods to reudce the JIT compile time？

I use the dr.set_flag(dr.JitFlag.PrintIR, True) to print the PTX code，the time before PTX code ouput is the JIT compile time？

[njroussel]

Hi @gnauk

This is unfortunate but there is some linear scaling that you cannot get rid of currently.

This should however be the tracing time (the time it takes the JIT to read/record the code) rather than the actual backend compilation. Basically, for every instance the JIT needs to record its functions. Of course, at the end, it will realize that they are all the same hence the compilation time should not grow but the tracing time should.

With PrintIR enabled, the PTX/LLVM IR will be printed as soon as the code has been assembled: the program has been traced and assembled but not yet compiled.

[gnauk]

Thanks.
For the bigger scene like above, the cpu version of mitsuba3 is faster than the llvm backend or the cuda backend through many experiments
, just because the tracing process waste too much time. This situation is exactly the opposite of the small scenes.

[njroussel]

This is good to know. Thank you for reporting this.