The OptiX_API_Reference_7.7.0 shows that maxTraceDepth=0 won’t allow optixTrace.
However, I find that I can call optixTrace once in __raygen__ and get correct results.
So, the “launch” in “a ray generation program can be launched” means the first optixTrace instead of optixLaunch? And maxTraceDepth=0 actually means no more optixTrace can be called inside optixTrace?
7.39.2.1 maxTraceDepth
unsigned int OptixPipelineLinkOptions::maxTraceDepth
Maximum trace recursion depth. 0 means a ray generation program can be launched, but can't trace any rays. The maximum allowed value is 31.
Ah you’re right the manual’s statement “can’t trace any rays” with max depth of zero is not literally always true. We can take the note to fix the language in the manual to be more accurate and descriptive.
By “can’t trace any rays”, the manually is really saying that tracing rays is not allowed, meaning you should not attempt to trace rays. It is not intended to mean that OptiX will prevent it from happening, especially if you disable error checking. When exceptions are turned off, then you have no error checking. When error checking is on, then you observe that an exception is thrown if you trace a ray when maxDepth is zero. This is working as intended, so we just need to update the manual to make sure it’s not accidentally misleading.
Be aware that just because on one machine you successfully traced a ray with max depth set to zero does not mean that it’s safe to do. It could crash or get corrupted when you change your code, or driver, or execution environment, or GPU, or run on another machine. Setting max depth to 0 leaves you without enough guaranteed stack space. That doesn’t guarantee it will crash. But if it happens to work, it’s an accident, and it could crash at any time. So be careful about assuming that something that works is safe. Use exceptions and validation mode often during development to catch some common problems.
Also note there are lots of features in OptiX and CUDA that might work accidentally, even when not allowed. The issue is that error checking reduces performance, so these toolkits support turning off a lot of error checking. This can sometimes be risky and confusing, so it’s important to use testing and error checking often, and for example to be careful with settings to make sure you have enough guaranteed stack space.