Graphics debugging not supported on mixed-GPU target system.

System Configuration: GT 730 (PRIMARY display device), GTX 1080 (x2), Windows 8.1 Professional, 388.59 WHQL drivers

Despite the dinosaur GT 730 GPU being the primary (and only) display device, NSight’s graphics debugger fails to start citing “Graphics debugging is not supported on this GPU”. The only way to run the graphics debugger is to disable the non-compliant (1080) cards in the Device Manager or to physically remove them from the system so that the Kepler card is the ONLY adapter in the system.

The 1080’s are used only for CUDA compute. Having to enable/disable them just to debug the graphical elements of the application is a bit silly (actually, it is a bit silly that THREE generations of graphics cards have come to market without any support in the toolchain for graphics debugging on any of these platforms). Please fix.

Thank you.

I totally agree with you. The beast-like computational power of nVidia’s hardware is impressive, but the quality of nVidia’s software is … impressive too. It is especially true for the support of Shader Debugging in Nsight. It has been almost half a year and none of my question on Shader Debugging receives any response, not to mention a satisfactory handling. To retrospect earlier, there seemed to be a dedicated employee for Shader Debugging problems, but she only asked the asker trivial questions like what the sample is, what the driver is, etc., and then no reply any more.

The documentation is problematic too. All the graphics cards that do not work with Shader Debugging are listed in the system requirements webpage. What is more ironical is that there is a footnote saying “new NVIDIA? Nsight? Visual Studio Edition 5.3 and newer metrics may not be available on Kepler-based GPUs.” It is because of this footnote that I purchased a GeForce Gtx 1050 Ti card, only to be told later that Shader Debugging only works with Kepler. Nowhere can you find this restriction in the documentation. Equally ironical is that most problems of Shader Debugging concentrate on Nsight versions after 5.3.

As for the mixed-GPU target system, I hope the Nsight developers in nVidia could expose an option to let users choose what card to use for different type of debugging task, or even better, automatically choose the supported card. Hoping this request is not ignored like all my past threads.

When I upgraded all my systems to Pascal-based GPU’s, I thought I was good to go! After all, it’s only logical that the toolchain evolves with the hardware, no? Confident in my purchase, I pulled my old 780 Ti and sold it for peanuts on the dollar. Doh! If I had only known this dinosaur GPU was required for GLSL debugging I’d have held onto it for dear life! I ended up having to go out and purchase a cheap GT 730 JUST so I could debug a shader for my client. But even with this card, shader debugging capability is very very brittle. Dumb.

The last time I was debugging shaders was back in 2013. Back then I was using AMD’s gDEB toolchain and it worked swimmingly. I am nothing short of alarmed to find that in 2018, there is almost nothing out there anymore for GLSL shader debugging on modern applications running modern GPUs. Even the GLSL open-source debugger still touted on the Khronos website has been abandoned (though it is purported to work for OpenGL 2.x and 3.x apps under 32-bit Linux…yaaaay). This is one of the rare moments in time where technology has actually regressed. Fixed function pipeline apps are dead; it’s all about the programmable pipleline and that means shaders, shaders, shaders. That should be PRIORITY #1 for any graphics debugging tool.

Sad. Makes me want to embrace HLSL and Microsoft’s PIX.