Closed merlinND closed 7 months ago
Hi @merlinND
For your first suggestion, I thought that this was the case unless we used the new/future JitFlag.Debug
. But it doesn't seem to be the case. @wjakob should I change this? or do you think it's particularly helpful to have the loop and condition titles in the IR without the debug flag?
(This obviously will only fix the issue in the nanobind-based branches we're working on.)
I also think that we should implement your second suggestion. In principle, whether the debug flag is used or not, should not have any (or as little as possible) consequences on the kernel launches and caching. If we can limit this in our own code, we should. I'll have a look at your PR.
In the next version of Dr.Jit, the title is optional -- it is simply "untitled"
by default. The issue reported here is a bit strange to me because including this label in the generated IR is in some sense the whole point of why such a label even exists.
I agree that the specific use case in binary_search
is potentially problematic, that function needs a major refactor in any case.
including this label in the generated IR is in some sense the whole point of why such a label even exists.
That's fair, in that case solution (2) is still relevant I think: we should avoid having varying loop titles that users don't have control over.
I just checked again and dr::binary_search
is actually the only example I could find, so if you agree with #214 this issue can be closed as well :)
Hi,
The following code:
leads to a new kernel compilation for each new loop title:
My understanding is that this is due to the loop title appearing all the way down in the JITted code. To avoid this, we could:
dr::binary_search
:https://github.com/mitsuba-renderer/drjit/blob/8f0976008f3662756bb078f713e383a98f944e1d/include/drjit/util.h#L187-L193
What do you think?