Hi @Bird33!
Yes good question. We are calling this a “preview” because indeed it is not fully functional yet, it works well in certain cases and not well in other cases, and we wanted to make sure users understand that this isn’t completely production ready. I’m putting together a video to explain in more detail what currently works.
As of right now, functions that have continuations in them can confuse the debugger. This means any call with optixTrace() or with a continuation callable call. I’m guessing your closest hit shader in this screenshot has one of those things. (If your virtual call stack is correct, I assume you have a trace call and that you’re stopped on a recursive invocation of closest hit.) You can try commenting the call and then seeing how your local variable inspection changes. Another thing that can cause issues is C structs, sometimes they aren’t displayed correctly or at all, whereas POD types (plain ol’ data like int/float) should appear correct. Knowing these limitations might in some cases allow you to write code that is slightly more debugger friendly, just be aware that we will be fixing these temporary limitations as soon as we can.
The virtual call stack can also get a little confused by continuations at the moment, but you may notice how useful the virtual callstack can be. It will show inlined function calls as if they are on the stack. This is a big improvement over not being able to see where an inlined function was called from. We are working toward exposing the virtual call stacks in Nsight Compute as well.
Breakpoints at the moment should work quite well, and crashes on memory access errors are also quite often helpful even when local variable inspection doesn’t work. We thought there was enough working in the debugger that it was worth “previewing” the progress and getting some feedback. The good news is that debugging will improve from here with driver updates, and won’t require an SDK upgrade.
–
David.