mitsuba3
mitsuba3 copied to clipboard
[Bug] drjit error when using batch of radiancemeters + llvm
Summary
When using a batch sensor containing radiancemeters, drjit throws an exception in llvm_spectral and llvm_ad_spectral. This doesn't happen if I use the scalar_spectral variant, or if I use perspective sensors instead of radiancemeters. The error is:
Caught a critical exception: drjit::detail::collect_indices(): encountered an uninitialized function argument while recording a virtual function call!
System configuration
System information:
OS: Windows-11 CPU: Intel64 Family 6 Model 151 Stepping 2, GenuineIntel GPU: NVIDIA GeForce GTX 1660 SUPER Python: 3.12.0 (tags/v3.12.0:0fb18b0, Oct 2 2023, 13:03:39) [MSC v.1935 64 bit (AMD64)] NVidia driver: 536.25 CUDA: 12.2.91 LLVM: 16.0.0
Dr.Jit: 0.4.6 (DEBUG) Mitsuba: 3.5.2 (DEBUG) Is custom build? False Compiled with: MSVC 19.37.32822.0 Variants: scalar_rgb llvm_mono scalar_spectral llvm_ad_spectral llvm_spectral
Description
I have narrowed down the scene to a minimal example with a single radiancemeter in the batch sensor. This error also does not happen when using a perspective sensor. The error
Caught a critical exception: drjit::detail::collect_indices(): encountered an uninitialized function argument while recording a virtual function call!
seems to happen by the end of the sample_ray_differential function in batch.cpp, just after calling the radiancemeter sample:
auto [ray, spec] = sensor->sample_ray_differential(
time, wavelength_sample, position_sample_2, aperture_sample,
active);
Which is strange since it seems to finish executing the radiancemeter->sample_ray_differential function.
It may be some misconfiguration on my part, thanks for any help!
Steps to reproduce
This radiancemeter.xml scene will throw the error when executing mitsuba -m llvm_ad_spectral radiancemeter.xml or mitsuba -m llvm_spectral radiancemeter.xml:
<scene version="2.1.0">
<!-- Defaults, these can be set via the command line: -Darg=value -->
<default name="resx" value="1"/>
<default name="resy" value="1"/>
<!-- Camera and Rendering Parameters -->
<integrator type="path" id="integrator" name="integrator">
<integer name="max_depth" value="-1"/>
<integer name="rr_depth" value="5000"/>
</integrator>
<!-- OPTION 1: -->
<!-- Caught a critical exception: drjit::detail::collect_indices(): encountered an uninitialized function argument while recording a virtual function call! -->
<sensor type="batch" id="sensor" name="sensor">
<film type="hdrfilm">
<string name="pixel_format" value="rgba"/>
<integer name="width" value="$resx"/>
<integer name="height" value="$resy"/>
</film>
<sensor type="radiancemeter" name="sensor_0000">
<transform name="to_world">
<rotate x="1" angle="89.999995674289"/>
<rotate z="1" angle="180.00000500895632"/>
<translate value="0.000000 -0.100000 0.000000"/>
</transform>
<film type="hdrfilm">
<string name="pixel_format" value="rgba"/>
<integer name="width" value="$resx"/>
<integer name="height" value="$resy"/>
</film>
</sensor>
</sensor>
<!-- Materials -->
<!-- Emitters -->
<shape type="rectangle" id="emitter" name="emitter">
<transform name="to_world">
<matrix value="10000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 -10000.000000 0.000000 0.000000 10000.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1.000000"/>
</transform>
<emitter type="area" name="emitter">
<spectrum value="1000.000000" name="radiance"/>
</emitter>
</shape>
<!-- Shapes -->
<!-- Volumes -->
</scene>
Alternatives that do work
- Executing the above scene with a scalar version:
mitsuba -m scalar_spectral radiancemeter.xml - Using the same scene, but replacing the batch sensor with the inner radiancemeter:
<sensor type="radiancemeter" name="sensor_0000">
<transform name="to_world">
<rotate x="1" angle="89.999995674289"/>
<rotate z="1" angle="180.00000500895632"/>
<translate value="0.000000 -0.100000 0.000000"/>
</transform>
<film type="hdrfilm">
<string name="pixel_format" value="rgba"/>
<integer name="width" value="$resx"/>
<integer name="height" value="$resy"/>
</film>
</sensor>
- Same scene, just replacing the inner radiancemeter with a perspective sensor:
<sensor type="batch" id="sensor" name="sensor">
<film type="hdrfilm">
<string name="pixel_format" value="rgba"/>
<integer name="width" value="$resx"/>
<integer name="height" value="$resy"/>
</film>
<sensor type="perspective" name="sensor_0000">
<transform name="to_world">
<rotate x="1" angle="89.999995674289"/>
<rotate z="1" angle="180.00000500895632"/>
<translate value="0.000000 -0.100000 0.000000"/>
</transform>
<film type="hdrfilm">
<string name="pixel_format" value="rgba"/>
<integer name="width" value="$resx"/>
<integer name="height" value="$resy"/>
</film>
</sensor>
</sensor>
Hello,
Were you able to find the underlying problem? Today I ran into the same problem, but in my case with the CUDA backend. I was trying to put multiple "radiencemeter" sensors into a "batch" sensor group to get them rendered efficiently.
Kind regards arwk
Hi @arwk, unfortunately I didn't manage to solve it. I didn't look into it very in depth after I realized the huge changes that are going on right now in drjit, as they could possibly remove the issue in the near future.
In the meantime, I just render the radiancemeters in a loop, which is quite slower but at least it works.
Best Nestor
Hi @nestor98
Sorry, I've somehow missed this entirely.
I'll try this out on the new upcoming Dr.JIT and report back :)
Hi @nestor98
Just wanted to share the workaround we came up with, which seems to work quite well. We are using an orthographic camera with a 1x1 pixel film, heavily scaled down to be almost point-like. This seems to approximate a radiencemeter quite well.
The following code defines such a sensor that is compatible with the batch-sensor-plugin
"approximated-radiencemeter": {
"type": "orthographic",
"to_world": mi.ScalarTransform4f.look_at(
origin=[0,0,3], target=[0, 0, 0], up=[0, 1, 0]
) @ mi.ScalarTransform4f.scale([.00001, .00001, 1]),
# Scale the 1x1 Pixel down, to mimic the radiencemeter
"film": {
"type": "hdrfilm",
"width": 1,
"height": 1,
"rfilter": {"type": "box"},
},
}
Hi @nestor98,
Apologies for the delay in getting back. This should now be resolved as of 944cb08 on master. I'll close this issue off but please reopen if you're still encountering issues after pulling the latest.