Unfortunately, the prognosis is not good. NSight GLSL shader debugging is VERY VERY brittle. No doubt NVidia is retiring this feature because the cost of supporting it across different architectures is prohibitive. This feature has become progressively more broken with each 5.x release and beyond. CUDA and Vulkan are NVidia’s focus; GLSL is not.
To date, I have only gotten it to work with the most basic of OpenGL samples. God help you if you’re using a GL toolkit of any kind. Some quirks I have noticed is that if you have a multi-GPU setup, even if one of your GPU’s is a Kepler card, you can’t set breakpoints unless you disable all other GPU devices (or physically remove them from the system). Also, the Visual Studio NSight plugin has a bug which took me months to puzzle out: namely, once you open a shader program you CAN NEVER CLOSE IT…doing so, will unload whatever binding the plugin has with the debugging engine. The only way to overcome this latter is to restart Visual Studio to reinitialize the plugin. Occasionally, I’ve had to purge the contents of %AppData%/Temp as well on the client. If your shader has a #line directive in it, it won’t work. If your shader program is compiled and loaded from a binary, you can’t debug/edit it either. Half the time I try to edit/compile a shader using DSE, NSight bombs out with an Internal Error. Bizarrely, Windows 7 and Windows 10 are supported but Windows 8/8.1 are not and sometimes you will need to run the target application in compatibility mode to have NSight not get angry. Multiple contexts? False. The list goes on and on. It truly is a house of cards. It’s just broken and it ain’t gettin’ fixed.
Unfortunately, we have regressed over the last decade where shader debugging is concerned (probably due to rapid advancements in pipeline architectures and processor design). There used to be 2 or 3 different open source solutions to shader debugging 5 or 6 years ago, but they’ve all dried up and died on the vine. NSight was the last bastion and its tower has also crumbled.
Your best avenue is to fallback to printf style debugging and using graphical methods to inspect the behavior of your shader. Also, NSight Graphics (standalone) is operationally superior and vastly more reliable than the VS plugin. You won’t be able to do step-wise shader debugging in that, however.