The pathtrace sample does raytracing iteratively - computes origin and direction in closest hit program and stores in PRD data, then ray generation program launces a new ray.
Why wasn’t it done recursively (e.g. launch new ray from closest hit program)? Was it done to avoid issues due stack size limitations? Or to simplify code by doing continuation checks in a single place instead of at every material / hit program?
What generally are performance implications doing it one way or the other?
This has come up in other topics.
Yes, it avoids issues with stack size limitations.
OptiX performs better with smaller stacks sizes, so doing an iterative launch is beneficial because you can reduce the size of the stack. Generally, this is what the OptiX devs recommend.
Thanks for the answer. I couldn’t find a similar topic discussed, the search engine doesn’t limit itself to OptiX section.
Can you comment on performance implications (supposing stack size is not an issue)?
I can. In my experiments I found that it really didn’t matter too much. If the stack was sufficiently large, both approaches performed about the same. However, I’m sure the results will vary depending on application. In mine, it was 20 relaunches, with large and complex kernels.
But, iterative is a lot easier to deal with. You don’t have to limit your retracing to your stack size or deal with stack overflows… Having more device memory to be used elsewhere can be very beneficial.
Thanks