Sebastien Speierer

After discussing with @njroussel , it was decided not to merge this PR into `master` due to the invasive nature of the changes and limited clarity on the use case...

Hi @GCChen97 , Could you confirm that this issue also arises with using the `llvm_ad_rgb` variant? Also did you check that the new `to_world` matrix has the expected values?

Working on a fix for this issue in #307. Hopefully, we will be able to merge this one soon and make another patch release.

You need to keep in mind that Dr.Jit will postpone all kernel compilation & evaluation until it can't do so, e.g. when the user calls `dr.eval()`. In your case, the...

Did you try the following? ```python for k, v in opt.items(): dr.schedule(v) dr.eval() ```

Actually it is important that you evaluate those values as well as their gradient values. Could you try the following: ```python for k, v in opt.items(): dr.schedule(v, dr.grad(v)) dr.eval() ```

Does this behavior still holds when using the `mi.render()` function? I would like to try this on my end if possible.

On my side most of the time is spent in `mi.render` and `dr.backward` using the following script: ```python import drjit as dr import mitsuba as mi mi.set_variant('llvm_ad_rgb') scene = mi.load_dict(mi.cornell_box())...

Actually, this really sounds like a bug to me. When performing such an asynchronous task (e.g. `Bitmap.write_async()`) we register the task so that Mitsuba can wait for its completion before...

Hi @ljijjiang1234 , Currently there is no good documentation on how to modify the codebase to make new parameters differentiable. Could you better explain what is it you are trying...