Debugging kernels from Nsight and Visual Studio using Attach to Process is difficult to get right. I've done my best to come up with a foolproof formula for getting it to work. I'm not 100% sure all the steps are absolutely necessary, so you may find it can be made simpler as you become more familiar with what works for you. Note that typically, order is important here - for instance you need to start the Nsight monitor before you run MATLAB.
1. Install the version of the CUDA Toolkit compatible with your version of MATLAB (type gpuDevice into MATLAB and check the ToolkitVersion). In R2014a, this is CUDA 5.5. You will need to ensure that the SDK is installed, but you should be able to use a later version of the driver and Nsight Visual Studio integration. 2. Run the Nsight Monitor (e.g. from the Start menu). Make sure it is set up to allow attaching to CUDA applications (right-click on Monitor icon in system tray -> select Options -> select CUDA -> change setting "Use the Monitor for CUDA attach" to True).
3. If you are using the same GPU as you are using to drive your display, you may need to disable/modify Windows Timeout Detection. Even if you have a separate compute GPU, Nsight monitor will warn you about TDR anyway so you may still want to make this change (right-click on Monitor icon in system tray -> select Options -> select General -> change WDDM TDR Delay to 10 or higher). 4. Open Visual Studio and open the source file containing the kernel you want to debug.
5. Run MATLAB from Windows Explorer or the Start Menu (as opposed to from a command prompt or Run box).
Info: This has to do with the way MATLAB is launched in a separate process from the command prompt. This has been known to confuse Visual Studio.
6.In MATLAB, set the NSIGHT_CUDA_DEBUGGER environment variable to 1:
setenv('NSIGHT_CUDA_DEBUGGER', '1')
7. Compile your MEX code following the documented instructions for your version of MATLAB (see the online documentation for latest, but older versions use a different process). It appears that getting Visual Studio to recognise kernel breakpoints initially depends on there being both host and device code debugging symbols present; and also on both the default and Nsight debuggers being attached. These requirements are true for at least the first time you debug your kernel. Typically you want both anyway because you want to debug both your host and your device code. Follow these instructions:
- For MEXCUDA (R2015b) pass -g (host code debug symbols) and -G (device code debug symbols) directly to MEXCUDA:
mexcuda -g -G mymexCode.cu
- For earlier versions, pass -g to MEX as above. To get device symbols, override the DEBUGFLAGS variable to add -G:
mex -largeArrayDims -g DEBUGFLAGS="--compiler-options=/Z7 -G" mymexCode.cu
- Another way is to edit the options file and insert -G into an appropriate place. Use the -v option to check what options where actually passed to nvcc.
Advanced: It is tempting for the advanced user to think they can use the -g option to nvcc rather than --compiler-options=/Z7. However, this uses the /Zi option to the msvc compiler and these symbols are not recognised when attached to MATLAB.
8. Run your code at least once to make sure the mex file is loaded.
9. In Visual Studio, open the Attach To Process dialog in the Debug menu.
10. Attach the default debugger by selecting MATLAB in the list of processes and clicking Attach.
Info: As mentioned above, attaching the default debugger may not be necessary in subsequent debugging runs.
11. Now open the Attach To Process dialog again.
12. Change 'Transport' to 'Nsight GPU Debugger'. Make sure your computer hostname is still selected in the 'Qualifier' box.
13. All being well so far, MATLAB should appear as one of the processes available to attach. Select it and click Attach.
Feedback: The first time you do this you should get a notification from Nsight Monitor by the system tray saying “Connected hostname to hostname”.
14. Put a breakpoint in your kernel code.
Feedback: If symbols are correctly loaded your breakpoint should remain solid red rather becoming hollow with a question mark. Also, it will often move to a new location because not every line of your kernel can be debugged due to optimisations.
15. In MATLAB, run your mex function again. The breakpoint should be hit and bring Visual Studio to the front. Start your debugging.
These are some other things that may help:
- In the Visual Studio Attach To Process dialog, the “Attach to:” box should automatically say “Automatic: Native code” if your code is not in a Visual Studio project. If you are having problems with this try changing this via the Select… button and make sure both Managed and Native code are selected. (This option can make Windows ignore breakpoints in code that isn’t managed by a Visual Studio project.)
- Try opening the Modules window in Visual Studio (Debug -> Windows -> Modules) and check that your mex file appears in the list with the Symbol Status saying “Symbols loaded”. If it doesn’t say this you definitely do not have debug symbols loaded for your file. Also check that the path to the file is the same as the path to the file in the editor where you have set your breakpoints.