I just updated to Cuda 12.1 and now can’t seem to get debugging to work in OptiX 7.6
I’ve updated to the latest Nsight that claims compatibility with Cuda 12.1 and latest drivers for my RTX 3090. It doesn’t work in my own projects and I tested on the optixHello sample in the OptiX 7.6 SDK and it does not work for me when I set a breakpoint and run Extensions->Nsight->Start Cuda Debugging from Visual Studio 2022.
Also printf() is not working either.
I tried debugging the CudaSamples and everything works as expected there.
I also tried on my laptop(RTX 3060) which is still using Cuda 12.0 and it works as expected too.
OptiX 7.6
Geforce RTX 3090 driver 531.18
Nsight Visual Studio Edition version 2023.1 build # 2023.10.23044
Windows 11 Pro
Can you try debugging after setting the environment variable OPTIX_FORCE_DEPRECATED_LAUNCHER to 1? I didn’t realize we were missing this info in the OptiX Programming Guide & Release Notes, we’ll get it fixed. For now there is a mention in the CUDA Programming Guide.
12.12. Debugging OptiX/RTCore applications
When debugging programs built with OptiX/RTCore, it may be necessary to set the environment variable OPTIX_FORCE_DEPRECATED_LAUNCHER to 1. If breakpoints are unable to be hit, try setting this environment variable before starting your application.
Sorry for the debugging bumps, this is a temporary workaround due to some underlying infrastructure changes we’re making.
With OPTIX_FORCE_DEPRECATED_LAUNCHER set, I am hitting break points now and printf() is working again too., But just so you know, I’m not getting any component values displayed for vectors like float3. I’m pretty sure that worked before the 12.1 update.
Yeah the support for showing locals and structs in the debugger hasn’t yet always worked reliably, especially inside a function containing an optixTrace() call, though I think it’s improving little by little. I believe it usually does work in functions without a trace call. So this might not be super helpful or convenient, but one thing you can try is temporarily commenting the trace call, that usually seems to increase the number of things visible in the debugger.
Does OPTIX_FORCE_DEPRECATED_LAUNCHER affect more than debugging feature?
My program that crashed only in Debug build without this env variable runs without crash when I set the variable.
Yes, it’s not about debugging features. It changes some internals about the launch mechanism, alas the environment variable name.
Do you have more information about the kind of crash you observed in a debug build target?
Error output?
The OptixModuleCompileOptions, OptixPipelineCompileOptions, OptixPipelineLinkOptions field values?
The system configuration information:
OS version, installed GPU(s), VRAM amount, display driver version, OptiX (major.minor.micro) version, CUDA toolkit version (major.minor) used to generate the input PTX, host compiler version.
Of course the best would be a minimal reproducer project in failing state.
