As title, the whole Windows system is dead when starting CUDA debugging in Visual Studio 2015. The Nsight Monitor displayed 50% translucent pop-up window saying connected to localhost. The CUDA project is created from the template “CUDA 9.2 Runtime” without any special configuration. I tried both Nsight 5.6 shipped with CUDA 9.2 and Night 5.3. It works if I debug step by step using VS’s own debugger. An msinfo file is here: Dropbox - File Deleted. Some of the environment info is below:
Windows 10 1803
Quadro K600
Driver 397.44
CUDA 9.2
Visual Studio 2015 Enterprise Update 3 version 14.0.25431.01
Nsight 5.3 or 5.6.
So what part of my system is Nsight unhappy with? K600 is too old? How to fix? Thanks.
K600 is a GK107 card and it should be supported, it it your display card? If you got system hang when hit the gpu break point, you should use software preemption mode to debug it.
Thank you. So the software preemption can avoid GPU halt, right?
I have only the K600 inserted into the MOBO; the intel embedded gpu seems disabled so K600 is the display card. I checked all the options of Nsight 5.6 and found that, if I didn’t miss anything, the software preemption options are only available under:
Monitor’s Options → CUDA(Legacy) → Desktop GPUs Must Use Software Preemption
Monitor’s Options → CUDA(Legacy) → Headless GPUs Must Use Software Preemption
Monitor’s Options → CUDA(Legacy) → TCC GPUs Must Use Software Preemption
Option in Nsight menu → CUDA → CUDA Debugger (Legacy) → Preemption Preference
Option in Nsight menu → CUDA → CUDA Debugger (Legacy) → Preemption Timeslicing
Option in Nsight menu → Graphics → Shader Debugging → Preferred Remote Shader Debugging
The settings of these options are shown in the screenshot. Because I have only one nVidia graphics card which is the display card, 2) and 3) are irrelevant. All other settings open the software preemption as much as possible. However, the Windows system is still dead when launching CUDA Debugging. I guess maybe software preemption was not implemented very well or even its support was terminated in recent versions of Nsight for Quadro K600. If that is the case, that’s a good news because that means the culpret is indeed GPU halt due to breakpoints. But a worse possibility is that there are bugs. My second Kepler graphics card is on the way. I will set up remote debugging when it arrives, when we’ll know if GPU halt is the cause. Let’s wait and see.
Actually nsight monitor prefers to use software preemption mode when you only have one GPU, could you try to set “visual studio → Nsight\Options\CUDA\Preemption Preference” to “Prefer Software Preemption”, disable all break point in your app, then check the NSIGHT->Windows->CUDA Info->Contexts->SW Preemption to make sure that sw preemption is enable
In order to pause in CUDA Debugger, I added for (;;); before return 0 (I can’t add it in device code because that’s equivalent to a breakpoint). But there is no “Contexts->SW Preemption” menu item under “NSIGHT->Windows->CUDA Info”. I am using Nsight 5.6.
You just need to click the CUDA Info 1, there will be a pop up window, you can check if you’re under software preemption mode.
Anyway if your system freezes when nsight hits a bp, I’m quite sure it’s sw preemption issue, the driver stops at cuda kernel and cannot do the display job.
Um, sorry I forgot two things, the first one is cuda info only works when you hit a bp, the second one is we only fully test gk104 and gk106, officially gk107 is not supported, I hope your second kepler card is one of them.
My next kepler card is GK110 (GeForce GTX 780 Ti). I’m going to cry …
So does gk107 (and GK110) absolutely not work with CUDA Debugging (and perhaps Shader Debugging)? That is, you only didn’t test it, so there is little hope that GK107 and GK110 still happens to be working?
Take it easy, because your system freezes when nsight hits a bp on your gk107, at least it means the break point works but the software preemption doesn’t work, I think it should work if you have a second card, call me when your get the second card.
Though my next card is still in transit, I got another same Quadro K600. After trials, the CUDA debugging finally works. Both machines have CUDA 9.1 and Nsight 5.5 installed (Windows 7 cannot install CUDA 9.2. On Windows 10 when CUDA 9.2 is installed, the client would report error that the version of target’s Nsight is 5.6 when actually the version installed is 5.5. Bugs anywhere. Sigh~) Here is some experience:
Local CUDA Debugging for K600 only works in Windows 7. The GPU doesn’t halt on breakpoints therein. As mentioned in one of my previous post, the whole system freezes on Windows 10 version 1803, because the K600 GPU halts on breakpoints in Win10. So I guess the root cause lies in the difference of handling software preemption between the two Windows systems.
For remote CUDA Debugging for K600, I can only use Windows 10 as host and Windows 7 as target. If we change the role of the two machines, the host (Windows 7) will complain that it cannot synchronize to the target (Windows 10):
So where is the “Nsight Output Log”? I’m so curious what on earth the problem is. PS: I have turned off the firewalls of both Windows machines, so nothing can prevent file copy except bugs in Nsight.
If you have two K600 on one computer, you just need to set CUDA_VISIBLE_DEVICES=1, then launch the nsight monitor, just make sure that the monitor can get this env variable, the cuda debugger will work on you second cuda card and you can debug you app on both win 10 and win 7 now, as gk107 is not officially supported and will be dropped in cuda 10, I think using a pascal card is a better choice.
I not only need to debug CUDA, but also want to debug GLSL. My previous graphics card is Pascal core GeForce GTX 1050 Ti. It plays very well with CUDA Debugging on Win10, but because only Kepler supports Shader Debugging, I sold it out.
I tried launching Monitor on the target as Administrator just now, but of no avail. However, I noticed that some specific error messages are output to VS2015.
In the Output window:
Nsight Debug
Synchronize error: IOException - The process cannot access the file 'Path_To_Project\testCUDA.VC.db' because it is being used by another process. - Path_To_Project\testCUDA.VC.db
Nsight Debug
Synchronize error: IOException - The process cannot access the file 'Path_To_Project\testCUDA.VC.VC.opendb' because it is being used by another process. - Path_To_Project\testCUDA.VC.VC.opendb
In the Error List window:
where the source code of kernel.cu around line 91 is:
// Launch a kernel on the GPU with one thread for each element.
addKernel<<<1, size>>>(dev_c, dev_a, dev_b);
The “<” immediately before 1 is underlined in red.
I don’t know what these info means. Do you have any idea? Thanks.
underlined red is excepted, visual studio cannot recognize <<< as it is a cuda not standard c++ operator, if the compiler doesn’t say anything wrong, that should be fine.