Does anyone know if its possible to Debug CUDA using parallel NSight on a remote machine? I am able to step into CUDA code but not my host code. It says CUDA has the capability to generate host debug information so debugging remotely and locally should be possible.
My card is a 580 GTX.
//device code <-- able to debug device code
//host code <---- when device code returns, should be able to debug host code
Thanks!
Simultaneous GPU/CPU debugging from a single IDE instance is unfortunately not possible with the current releases of Nsight and Visual Studio.
As a workaround, you can start GPU debugging from one copy of Visual Studio, then open a second IDE instance and attach its CPU debugger. They won't have unified stepping, but you can at least set breakpoints independently.
It should now be possible to attach both the Visual Studio default debugger and NSight in the same VS instance. Then this should work.
Related
I have a single GPU in my Windows 7 system. Would like to debug my gpu code locally on this machine.
There is a confusion regarding this. Do I need to do headless debugging, (may be making my on-board display as display driver), as explained in Setup Local Headless GPU Debugging?
Or do I need not do any thing like that?
You cannot do local headless debugging with only a single GPU. Headless means there is no monitor or active display attached to the GPU that is running the code under debug. If you are debugging locally, you need this display to see the nsight GUI and your windows desktop.
Single GPU local (non-headless) debugging is covered in the nsight manual.
If you can enable another GPU (need not be an NVIDIA GPU), then you can use that GPU for your windows display, and do headless debugging on the NVIDIA GPU.
I have CUDA 5.5, latest drivers, Nsight studio 3.1 for VC2010 on Windows7 64bit.
The target machine has a headless Titan card, and another simple NVidia card, to which the monitor is connected.
I'm trying to debug my CUDA code which includes some dynamic parallelism. Whenever I click "Start CUDA Debugging" in VC, I get this error from Nsight Monitor: CUDA dynamic parallelism debugging is not supported in preemption mode. From what little I found regarding this issue, this is because I'm trying to debug CUDA on the same device that drives my screen. This however is not true, as I mentioned, I have a separate card to drive the screen.
I went even further with this, disconnected the monitor from the second card as well, rebooted, and set up remote debugging from a different machine. Same result.
Does anyone have an idea how to tackle this?
Right click the monitor's tray icon, check "Options\CUDA\Debugger". Except TCC GPUs, the others are by default force "Software Preemption".
You can set "Desktop GPUS must use Software Preemption" and "Headless GPUs must use software preemption" to false. And make sure in you VisualStuido, the setting "Nsight\Options\CUDA\Preemption Preference" is "Prefer no Software Preemption".
I would like to start a remote debugging session from my development pc on our soon-to-be production server. On the server I start NSight using the remote desktop, and then I try to Start CUDA Debugging on my local machine (given the server as target before). The result is, that the debug session disconnects saying "The remote system is logged in through remote desktop. WDDM adapters will not be debuggable".
Is this intended behaviour, a bug, wrong configuration? And if there is no solution involveing remote desktop, how could I start the NSight monitor, so that I can start a debugging session?
On the target server I have two Tesla K10 and a Quadro FX (for Display). All Tesla devices (which are actually four), show TCC turned on.
I am using NSight 3.0, CUDA 5.0 and Visual Studio 2008 (the latter two only on the development workstation).
One last thing: Copying the application to the server and executing through remote desktop works fine.
The message you refer to is a warning to let users know that Nsight has detected that you have a RDP session running on the target side and that it won't be able to do Nsight debugging on any WDDM cards in it, if there is one (or more) - which looks like you do, with that Quadro FX that you mentioned).
This message is a Warning, and it should continue to let you run or debug the application under Nsight and debug the application assuming GPU code runs on the TCC devices. Are you sure the application ran successfully on the target machine? Can you double check that you have set a GPU breakpoint and see if you hit those breakpoint(s)?
Are there any other messages shown? - you can check the VS Output window.
Which driver version are you using?
Can you try running (double clicking) the application on the server but from the directory that Nsight synced the application to? It should be under %appdata\NVIDIA Corporation\Nsight\Monitor\Mirror\<hostdev_machine_name>\<path_to_the_sync_app>
I know you mentioned you tried copying it, but I'd like to see if everything that Nsight sync is what's required by the application and that maybe there's not something missing that you need to specify to sync (more info on syncing is here: http://http.developer.nvidia.com/NsightVisualStudio/3.0/Documentation/UserGuide/HTML/Content/Synchronization.htm)
Thank you
Nvidia has released extended eclipse for CUDA 5. They have Nsight plugin for VS2010 also. In VS2010 we can stop program execution at breakpoint in kernel but how to achieve this functionality in eclipse on Linux? I don't see any nsight specific keys to stop execution. I tried changing perspective but it debugs as a normal C/C++ application. I'm using Tesla C2070, Intel Xeon 8 core machine with Linux.
I'm from Nsight Eclipse Edition team.
Our goal is specifically for the application to be debugged as a normal C/C++ application. This means that you can set breakpoints, use "run to line", etc. regardless of whether you debug host or device code.
Basically, the process is quite standard for Eclipse:
Create a project (you can also import existing executable)
Click debug button
Debugger will run and by default will break in the main function. Note that no device code posted on the device so you will only see the host thread.
Set a breakpoint in the device code and hit resume (note that Breakpoints view toolbar also allows you setting breakpoint on any CUDA kernel launch)
Debugger will break when device code reaches the breakpoint. You can inspect your application state using visual debugger UI.
Couple things, and not sure which solved the issue. Drivers updated to latest ones with RC5.0, but I chose to run VNC server instead of native X server. Then the CUDA card(s) are dedicated to my apps and debugging, and it works like a charm, and now accessible from everywhere.
Eugene,
I just installed Cuda 5, and I wasn't able to break in any kernel code. It was a clean install of centos 5.5, with a fresh download of cuda-5, and i am running on a asus g71x laptop which has a gtx260m installed.
I thought maybe you cant run display and dedbug on one device still, so i switched to non-nv x display, but still had same issue, cant stop in the kernel code.
Have you tried CUDA 5.0 RC1? It is available now. You can download and try it. And I have tried the Nsight in it, it works well for debugging.
Best regards!
The 304.43 NVIDIA Driver does not let users other than root debug their CUDA application.
That problem is not present in any past or future public releases. The CUDA documentation recommends using only drivers listed in the CUDA DevZone. The 304.43 driver is not one of them.
That may or may not be the issue you are hitting. But I thought it was worth mentioning.
I'm trying to determine where a slowdown is occurring in my GPU code. I've verified that the code runs correctly on its own (it doesn't throw any errors, outputs are correct, finishes cleanly, etc). When I try to profile the code in Visual Profiler, it seems to run normally, dumping correct intermediate outputs to stdout. The GPU is being used (I've checked with cuda-gdb and dumping printf()s from inside my kernels). Once all the code has completed, Visual Profiler reports that viper has terminated the executable. However, no timeline is generated. Instead, the main window shows 0, 10, 20, 25 microseconds all "collapsed" on top of one another. When I tell the Visual Profiler to run all analysis options, it proceeds through the 24 runs without problems, but still no timeline is generated.
I'm using CUDA 4.2, driver version 295.41 on Ubuntu x86_64 with a GeForce 460.
When the visual profiler fails to generate a timeline it is typically because it cannot locate a component required for profiling. This component is a shared library found in /usr/local/cuda/lib64 called libcuinj.so. Is that path on your LD_LIBRARY_PATH? How are you launching the Visual Profiler? The script in /usr/local/cuda/bin/nvvp should set the path correctly for you.
The 4.2 version of the visual profiler does not do a good job of reporting errors when this shared library is not found. The upcoming 5.0 version of the visual profiler has much better error reporting in this regard.
I don't know if it's the same under Linux, but in Nsight under Windows, there are two basic types of profiling that you can run. "Application trace" and "Profile". Only under Application trace do you get the timelines. Application trace records the timestamps when CUDA and kernel calls were made. The Profile setting offers options to analyze the kernels. It reads the hardware counters from the GPU and generates performance information related to one or multiple kernels (and no timelines).