Debugging JIT compiled code line by line

[dhart]

Full symbolic debugging of OptiX programs in cuda-gdb isn’t supported yet, we are working on that. SASS level debugging works, but you have to figure out the correspondence to your source code manually. That can be pretty difficult, I don’t expect that to be a helpful suggestion or viable workaround unless you are extremely comfortable with assembly debugging. Breakpoints sometimes work, so you may be able to use them to help narrow down the region causing your misaligned address exception.

Here are a couple of threads with some suggestions for other possible ways to debug:

How can I debug the .cu shaders of OptiX in linux

Hi, here is a list of things you can check: Use OPTIX_COMPILE_OPTIMIZATION_LEVEL_0 Use OPTIX_COMPILE_DEBUG_LEVEL_FULL Install the latest driver, if you haven’t already Install the latest version of cuda_gdb, if you haven’t already Note that cuda-gdb debugging is not up to the same level of OptiX support as Nsight VSE. With cuda-gdb, breakpoints will usually work, but you will not be able to step through source code, you can only step through assembly. You can currently monitor registers, but …

Vector functions for OptiX 7 with NVRTC?

Hi, yes GTX 1050 is fine, there is no difference for Nsight debugging GTX vs RTX. By “watch” I assume you mean setting a breakpoint that is conditioned on a variable being equal to some value you choose? I haven’t been able to try this today in OptiX, but the Nsight VSE manual says you can set conditional breakpoints. If this works in OptiX programs, you will probably have to create a local variable with your pixel coordinates (via optixGetLaunchIndex) in order to get this to break on a pixel …

(see the print_pixel macro)

–
David.