Release Notes

NVIDIA® Nsight™ Development Platform, Visual Studio Edition 2.2 User Guide
Send Feedback

---

1. The CUDA Info pages now persist sort status when switching between pages. (15113)
2. The "No Source available" page is no longer displayed when the CUDA Debugger steps into a function pointer. (14983)
3. When stopped at a syscall (e.g., assert, printf), the values of variables and registers in previous stack frames are now available. (13700)

1. MMU faults caused by invalid global memory accesses are not detected or reported by the debugger when debugging on a Kepler architecture (e.g., GeForce GTX 680). Please use the Memory Checker to detect these types of errors.

2. If multiple CUDA Info tool windows are open and one or more of them are hidden, the other tool window(s) will not refresh. Bringing the hidden windows to the foreground will workaround this issue. (17033)

3. All __shared__ variables declared at function scope are showing in the Visual Studio Locals window. This can occur because the compiler may erroneously present all function-scoped __shared__ variables as global variables in the debug symbols. (15122)
   For example, in the following code, ‘ss’ will show in the Locals View when the current stack frame points at a different function.
   

   __global__ void kernel(void)

   {

       __shared__ int ss;

       if (threadIdx.x == 0)

           ss = 0;

   } 

4. You must enable Memory Checker before launching a process, and cannot change the setting while debugging. (14463)

5. When the CUDA Debugger is used to debug CUDA applications which share resources with DirectX 9 (such as the “simpleD3D9” sample program), the debugger may display incorrect values for memory locations in those shared resources. This may happen when the GPU device executing the application is Compute Capability 2.0 or higher. Incorrect values for the contents of memory may be displayed in any debug window (Autos, Locals, Watch, Warp Watch, or Memory). This issue does not affect applications using DirectX 10 or DirectX 11. (13899)

6. On Fermi GPUs, after an MMU fault, the CUDA Debugger will not resume normally. The application may still be terminated. (13808)

7. With CUDA 4.0 Toolkit, function pointers show as type void* in the locals, watch, and Warp Watch tool windows.
   With CUDA 4.1 and 4.2 Toolkit, function pointers show as type __device__ func* in the locals, watch, and Warp Watch tool windows. The value contains the function address and mangled function name. (11786)

   For example: 0x0001ba80 _Z11funcPtrTestiPcf __device__ func* __local__

8. When using the CUDA Debugger with NVIDIA Nsight, breakpoints will not be hit in source files whose full paths contain non-ASCII characters. Any path with a character code >= 128 is affected.  (11429)
9. When using the disassembly view, stepping to an instruction that has an associated source line with a breakpoint will bring the source file to appear on top of the disassembly document. This is standard Visual Studio behavior.
   Likewise, when stepping in assembly, Visual Studio may get the breakpoint hit count updated incorrectly in the breakpoint view. (11347)
   

10. If you experience hangs or TDRs while locally debugging CUDA on a single GPU (or using the Software Preemption debugging mode in general), try disabling Aero and WPF acceleration on the target machine.

11. Variables do not appear for source code that is not executed. This occurs because the compiler aggressively optimizes code even if you have not specified any compiler optimizations. As a result, the compiler removes any code that will not be executed from the output executable.
12. Breakpoints will hit multiple times on lines that have more than one inline function call. For example, setting a breakpoint on:
    x = cos() + sin()
    will generate three breakpoints on that line. One for the evaluation of the expression, plus one for each function on the line.
13. On Tesla architecture GPUs (e.g., GeForce GTX 260, Tesla™ C1060), hitting a breakpoint may prevent HW error detection. It is possible that errors can be masked in the following situation:
    - Launch CUDA kernel with 2 blocks running on different SMs; each block has 1 warp.
    - Warp A hits a breakpoint while concurrently warp B does a write to an invalid address.
    In this situation, the launch would succeed - but if run without breakpoints, a launch failure would occur.
    The above is just an example. It is possible that there are other ways for this to occur.
14. Unloading modules does not refresh the state of breakpoints set in that module. This means that those breakpoints do not show their latest state in Visual Studio when they have been unloaded.
15. The Visual Studio Breakpoint "Filter" option is not supported for CUDA GPU breakpoints.
16. The Visual Studio Breakpoint "Hitcount" option is not supported for CUDA GPU breakpoints.
17. When starting Graphics or CUDA Debugging in Visual Studio, the user cannot specify environment variables to be used in the environment block of the launched process.
18. The F5 hotkey (which is the default hotkey in Visual Studio for starting the CPU Debugger) does not start the CUDA Debugger.
    To start the CUDA Debugger, you must either change the key bindings or use the menu command:
    Nsight > Start CUDA Debugging.
19. There is no support for automatically performing a Build when launching the CUDA Debugger.
20. The Load Symbols option, or "Symbols settings," in the Modules view is not supported for CUDA debugging.
21. When application execution is paused on a line of code that contains a conditional statement (such as an IF or WHILE statement), if you Step Over the statement, the CUDA Debugger does not pause at the next line of code after the conditional statement (after the closing curly brace). Instead, the CUDA Debugger pauses execution on the last line of code in the branch that was executed. This happens because of the way the compiler emits line tables, and treats curly braces. For more information on this unexpected behavior, see the article in the NVIDIA Nsight Knowledge Base titled "Run Control and Conditional Statements in CUDA Code." (5199)

1. Support for the new Kepler architecture (for example, found in the GeForce GTX 680).
2. Support DirectX 9 for Frame Debugging, Frame Profiling, and analysis.
3. Improved Frame Profiler with performance improvements and additional experiments.
4. Improved Frame Debugger Visual Studio frame scrubbing performance.

1. Fixed some instances of not seeing the geometry preview and now properly declare which situations are not supported (like DrawAuto).

2. Better handling of out of memory situations when profiling or saving a capture to disk.

3. Performance improvements to the profiler, reducing the number of passes needed to calculate the bottleneck and utilization results.

4. NVIDIA Nsight now handles applications that spawn other applications (like an external compile). These processes are ignored and should not hang the main process. This also means that NVIDIA Nsight is not compatible with applications that use a launcher. Disable your launcher.exe and instead have NVIDIA Nsight launch engine.exe to work with this type of setup.

5. Improved support and stability when running on non-NVIDIA GPUs or in a mixed vendor system.

6. Fixed an issue where the geometry preview was not updated when changing the draw call from the top scrub bar. (12369)

7. The draw call page can be changed while it is loading with no impact on stability. (12383)

8. SlimDX is now fully supported by NVIDIA Nsight, with the exception of samples built with the AnyCPU configuration.

1. There are two DX shader compiler bugs that may cause incorrect stepping behavior.

   1. The DX shader compiler will map "end-of-block" instructions to the beginning line number of the block in the HLSL source.
   2. The DX shader compiler will map "implicit" returns to the beginning line number of the shader.
      This issue can be resolved by always adding an "explicit" return at the end of your shader. (14656)

2. NVIDIA Nsight does not support debugging managed applications built with the AnyCpu configuration. The target application must be built using either the Win32 or x64 configurations.

3. NVIDIA Nsight for Graphics uses a setting in the driver that enables instrumentation. If the application does not close cleanly, this setting can remain enabled, which can cause some additional CPU overhead. The Nsight Monitor has an option to disable this, in case you see any issues running your application outside of Nsight. (16936, 16962)

4. In some cases, very small vertex buffers cannot be retrieved from the GPU, so the Vertices3D view in the Graphics Focus Picker may not display the correct input vertices. (14192)

5. For drivers prior to R295, there is a performance bug in the pixel pipeline when running your application in NVIDIA Nsight. This will lead to higher values in the Frame Profiler for bottleneck and utilization, especially in the shader, texture, blending, and frame buffer units. This issue will be fixed in the R295 driver.

6. There are known issues in the R290 series of drivers that can cause the shader debugger to not hit a break point and/or cause corruption in the rendering when breakpoints are set. These have been fixed in the R295 driver and have not been seen in the R285 drivers. If you encounter these issues, please change drivers. (15602)

7. If a pipeline stage does not have an object bound, then the related state is not displayed on the host. In this case, there is no pixel shader bound, so there are no Shader Resource Views shown. (15394)

8. HLSL code cannot contain any non-ASCII characters. Any character with a character code >= 128 is not supported. (14760)

9. NVIDIA Nsight does not support applications that intercept Direct3D devices or objects by use of a shim object. This interferes with NVIDIA Nsight' internal mechanism and therefore cannot be handled properly. (14470)
10. On drivers prior to the 290.24 release, if you perform any operations that use the shader debugger (such as HLSL debugging or running a Pixel History), the performance of your application may remain diminished until you exit your application, even after you stop using those features. To ensure accurate profiling, we suggest you don't combine shader debugging and profiling activities in the same run of your application. (14329)
11. NVIDIA Nsight does not support debugging when running with Stereoscopic 3D. This will be fixed in a future version. In the meantime, please run your application with Stereoscopic 3D Stereo disabled when debugging with NVIDIA Nsight. (12618)

12. VS tracepoints, enabled by the "When Hit” breakpoint option, do not work as expected when the "Continue Execution" option is also set. Only the first hit will be reported and the target application will hang afterwards. You will need to select Debug > Stop Debugging to resume the debug target. (10904)

13. Source code syntax highlighting and the population of the autos window with your programs variables is set up with a file extension to programming language mapping. If these are not working, you can add the extension for your HLSL source code files to the list in the Tools > Options dialog under the Text Editor > File Extension section, and associate them with Microsoft Visual C++. (12094)
14. The Graphics Debugger’s Autos window may not show all variables as expected. This may happen if a shader is compiled using preprocessor macros to conditionally include or exclude code lines, and those macro definitions may only be available at shader compile time. (12094)
15. Replay-on-thread: Although fullscreen generally works, some applications may lose fullscreen status during the transition, and in windowed mode the replay window may occlude all other windows. If these issues become a problem, try changing the default behavior:
    1. When an application starts, press Ctrl-Z on the target to enable NVIDIA Nsight.
    2. Press T on the keyboard to toggle replay-on-thread.
16. The Graphics Debugger does not support the Reference Rasterizer (RefRast) tool, which is the CPU rasterizer provided by Microsoft. The Graphics Debugger will signal an error if the D3D10_CREATE_DEVICE_SWITCH_TO_REF constant is used in device creation.
17. You cannot access or see some variables in the Watch window because of optimization performed by the HLSL compiler.
18. You cannot set breakpoints on certain lines of source code if the HLSL compiler optimizes the lines out.
19. Forcing the target application to close through the task manager while in the frame debugger crashes the target application.
20. Expression evaluation and breakpoint conditions do not support HLSL built-in functions and vector and matrix expressions.
21. The following are limited in the Graphics Debugger:
    • Visualization of Depth-Stencil formats in Visual Studio. We show the depth part of a DS format, but not the stencil. Note that this is not a limitation on the target application when running with NVIDIA Nsight. You can switch between Render Target, Depth, or Stencil through the NVIDIA Nsight HUD toolbar while the target application is being debugged.
    • Examination of integer-based textures (DXGI formats that end in SinT or UinT).

1. CUDA kernels compiled with toolkits older than CUDA 4.0 are now fully supported for trace activities and profile activities.
2. Fixed a possible issue of corrupted profile data or application crash for profile activities on applications with a very high memory footprint.
3. Fixed an issue with incorrectly resolving system modules for captures with enabled stack trace capture.

4. Opening a new activity no longer fails when the default activity type is set to Profile. (16935)

5. On 64-bit systems, the stack trace in which only the stack frame pointers were reported has now been resolved. (16924)

6. Tracing sessions involving managed processes no longer shows error dialogs on the target system. (16964)

7. Manually started captures of CUDA API trace no longer fails to load properly. (16922)

8. Summary sections now display regardless of how much GPU data is captured. (16961)

9. Applications using CUDA-DX-interop no longer fail when traced with the DX provider enabled. (16842)

10. The activity page no longer misses the OpenGL sub-option for capturing GPU frames. (16977)

• Do not start an analysis capture session when the CUDA Debugger is paused on a breakpoint. Doing so can cause the system to crash. (3203)