Integrate .cu .cpp and .mex64 file under matlab

Accelerated Computing CUDA CUDA Programming and Performance
1

Hello,

I am trying to connect a cuda code from the samples, the one that adds two vectors, with matlab.
I have created a VS 2010 project that contains a .cu and a .cpp file. In order to call the .cu file I have made a wrapper function that is called via the .cpp file. For this project I can debug either the .cpp file with the VS or the .cu with Nsight with no problem. The next step was to convert the main function in the .cpp file with the mexfunction in order to run the .cu function via matlab. Unfortunately, when I set some break points in VS and attaching the matlab in VS, the breaking points did not work. It says that the break point will not currently be hit. The reason I am making the post here is because I do not think that this is a fault of mexfunction because I had make a template mexfunction example without cuda and the debugging worked, e.i the run of the program stopped in the break point. I have enabled the option in the VS to generate debug info either in c/c++ or CUDA c/c++ settings. Of course I am working in debug mode and I have my setting in 64x mode. Also I have the .pdb file in the same folder with .mexw64 file.

I am a user of Win 7 64x, Visual studio 2010 and matlab 2011a 64x, CUDA SDK 5.5 and I am using GeForce 9600 GT.

Thank you in advance.

PS: The .cu file was borrowed from Cuda SDK 5.5 64x, moreover in the attached file all the necessary files are included in order to build the project indepedently.

2

To hit any GPU breakpoints in MATLAB CUDA code you will need to attach to the Matlab process using NSignt… been there, done that. :) There is a variable you need to set in order to be able to attach to MATLAB from NSight, I don’t remember it offhand.

Likewise, to hit CPU breakpoints, you will have to attach to the MATLAB process with Visual Studio.

3

The environmental variable is NSIGHT_CUDA_DEBUGGER=1.

There is a relevant thread at

[url]visual studio 2010 - Debug cuda kernel on mexfunction by attaching Matlab with Nsight GPU Debugger - Stack Overflow

I have been unsuccessful to attach Visual Studio 2010 to Matlab for debugging CUDA mex files.

4

Yes, that is the correct variable. Also, the NVIDIA Monitor has to be running and enabled to be able to attach to the process, it’s one of the options on the GUI. I forget offhand because I’m on Linux at the moment.

5

Yes, I have already set “use this monitor for CUDA attach” as true. Let me recapitulate my problem:

  1. Turn on the Nsight Monitor and set “use this monitor for CUDA attach” as true;
  2. Set breakpoints and compile the CUDA mexfile;
  3. Turn on Matlab;

At this point, I should attach Visual Studio 2010 to a CUDA process. However, I have not yet launched the Matlab CUDA mexfunction, so my question is: to which CUDA process should I attach?

6

When I got it to work, I attached the NSight debugger to the MATLAB process, it does not matter if the CUDA process is active when you initially attach to MATLAB. I compiled the mex as 64-bit because MATLAB was also 64-bit. I am not sure if it would work if your CUDA app is 32 bit and MATLAB is 64 bit, or vice-versa. I’ll try to reproduce it again when I get the chance and maybe post the relevant steps.

Edit:

I reproduced it successfully, and here are the steps I took:

Here is a snippet on how to set up the Visual Studio environment for building a mex file (jorre’s answer):
[url]matlab - How to build mex file directly in Visual Studio? - Stack Overflow

While you’re setting environment variables, create one named: NSIGHT_CUDA_DEBUGGER and give it a value of 1.

Besides the tips mentioned in the stackoverflow link above, I would also name the Visual Studio project the same as the mex file name you want to run/debug with MATLAB, and under the project properties, output directory, just make it: $(SolutionDir)\ This directory should also have the relevant MATLAB code that calls the mex file. Usually Visual Studio makes a directory under the path of the current directory you tell it to – I just end up moving the solution files one level up and deleting that, so for me SolutionDir is where I also keep my source code.

I also had to add cuda.lib in order to be able to compile a function that reports GPU memory usage to the already existing linker libraries when I made a new CUDA 5.5 Visual Studio project type from the existing template.

After compiling with debug symbols in x64 mode, start MATLAB x64, and leave it on standby to execute your M code that calls the created .mexw64 file.

Next, go to DEBUG menu in Visual Studio and select ‘Attach to Process’. Pick ‘Nsight GPU Debugger’ Transport for debugging GPU code, and type: localhost as the qualifier (assuming you’re debugging on your local machine) and click ‘Refresh’. You should see MATLAB process selectable now – select it and click ‘Attach’. At this point, if you stop debugging, your MATLAB process will exit, just a warning. :) Set your breakpoints in Visual Studio at this point.

Now, back to MATLAB, run the M code that calls the mex file, and you should be able to step through the breakpoints you set. Confusing eh? ;) Just replicated this on Visual Studio 2012, MATLAB R2013b, Windows 8.1 RTM, and NSight Visual Studio build 3.1.0.13233, so even under the latest software it works just fine. :)

As an aside, last time I tried to do this, I didn’t even compile the mex file under Visual Studio (because I couldn’t figure out how to do it at the time, ha!), and did it with the help of a gmex script that Accelereyes had bundled into their Jacket SDK distribution. As long as I had compiled with debug symbols (-G), I was able to place breakpoints in the code and attach it in the same way as above, without actually having to compile it under Visual Studio. Obviously if I changed something in the code, I’d have to recompile via MATLAB with the gmex script, so it was a bit more painful.

I actually just re-tested this method and it also still works – no need to even compile it under Visual Studio as long as it’s compiled with debug symbols via the gmex method – my project is simple, so it only had one .cu file. This might not work if the mex file is divided into several .cu/.cpp files. YMMV. However, the first method should always work.

7

The procedure finally worked after a fresh re-installation of Matlab. Perhaps I previously had a not properly working Matlab installation. I summarize the procedure for the sake of convenience.

You can debug Matlab mexfiles including CUDA codes using Visual Studio and NVIDIA Nsight for Visual Studio by the following procedure.

  1. Define the system environmental variable NSIGHT_CUDA_DEBUGGER and set it to 1.
  2. Launch Matlab.
  3. Launch NVIDIA Nsight. Right click on the Nsight Monitor icon on the taskbar and select Options. Select the CUDA tab. For the option Use this Monitor for CUDA attach, click the drop-down menu and select True.
  4. Open your project in Visual Studio, set the breakpoints and compile it.
  5. Go to Tools -> Attach to Process.
  6. Click the drop-down menu next to the Transport field, and choose Nsight GPU Debugger.
  7. Ensure that your host machine name is listed in the Qualifier field. Note that this field is blank by default; you will have to manually select your machine name the first time this dialog is opened.
  8. When you enter your computer's hostname in the Qualifier field, a list of available processes will appear in the dialog box. Processes that may be attached with CUDA usage will appear with CUDA listed in the Type column. If a process is grayed out and CUDA is listed in the Type column, it is already being debugged, so it is not attachable. Processes that are grayed out without CUDA in the Type column indicates that it has no CUDA usage in the process to be debugged. Processes that may be attached will appear normally, and the Attach button will be enabled.
  9. Ensure that Matlab has CUDA in the Type column and select it.
  10. From the Matlab command line, invoke the function defined in the CUDA mexfile. The execution will then stop at the first breakpoint and debugging could start.