4. Nsight Compute CLI
The User Guide for Nsight Compute CLI.
4.1. Introduction
NVIDIA Nsight Compute CLI (ncu) provides a non-interactive way to profile applications from the command line. It can print the results directly on the command line or store them in a report file. It can also be used to simply launch the target application (see General for details) and later attach with NVIDIA Nsight Compute or another ncu instance.
For users migrating from nvprof to NVIDIA Nsight Compute, please additionally see the Nvprof Transition Guide for comparison of features and workflows.
4.2. Quickstart
Launch the target application with the command line profiler
The command line profiler launches the target application, instruments the target API, and collects profile results for the specified kernels. The CLI executable is called ncu. A shortcut with this name is located in the base directory of the NVIDIA Nsight Compute installation. The actual executable is located in the folder
target\windows-desktop-win7-x64
on Windows ortarget/linux-desktop-glibc_2_11_3-x64
on Linux. By default, NVIDIA Nsight Compute is installed in/usr/local/cuda-<cuda-version>/NsightCompute-<version>
on Linux and inC:\Program Files\NVIDIA Corporation\Nsight Compute <version>
on Windows.To collect the
basic
set for all kernel launches in the target application, launch:$ ncu -o profile CuVectorAddMulti.exe
The application runs in instrumented mode and for each kernel launch, a profile result is created. The results are written by default to profile.nsight-cuprof. Each output from the compute profiler starts with
==PROF==
The other lines are output from the application itself. For each profiled kernel, the name of the kernel function and the progress of data collection is shown. To collect all requested profile information, it may be required to replay the kernels multiple times. The total number of replay passes per kernel is shown after profiling has completed.[Vector addition of 1144477 elements] ==PROF== Connected to process 5268 Copy input data from the host memory to the CUDA device CUDA kernel launch A with 4471 blocks of 256 threads ==PROF== Profiling "vectorAdd_A" - 0: 0%....50%....100% - 46 passes CUDA kernel launch B with 4471 blocks of 256 threads ==PROF== Profiling "vectorAdd_B" - 1: 0%....50%....100% - 46 passes Copy output data from the CUDA device to the host memory Done ==PROF== Disconnected from process 5268 ==PROF== Report: profile.ncu-rep
Customizing data collection
Options are available to specify for which kernels data should be collected.
-c
limits the number of kernel launches collected.-s
skips the given number of kernels before data collection starts.-k
allows you to filter the kernels by a regex match of their names.--kernel-id
allows you to filter kernels by context, stream, name and invocation, similar to nvprof.To limit what should be collected for each kernel launch, specify the exact *.section (files) by their identifier using
--section
. Each section file defines a set of metrics to be collected, grouped logically to solve a specific performance question. By default, the sections associated with thebasic
set are collected. Use--list-sets
to see the list of currently available sets. Use--list-sections
to see the list of currently available sections. The default search directory and location of pre-defined section files is also calledsections/
. See the Profiling Guide for more details.Alternatively, you can collect a set of individual metrics using
--metrics
. The available metrics can be queried using--query-metrics
. For an explanation of the naming conventions and structuring of metrics, see Metrics Structure.Most metrics in NVIDIA Nsight Compute are named using a base name and various suffixes, e.g. sm__throughput.avg.pct_of_peak_sustained_elapsed. The base name is sm__throughput and the suffix is avg.pct_of_peak_sustained_elapsed. This is because most metrics follow the same structure and have the same set of suffixes. You need to pass the base or full name to NVIDIA Nsight Compute when selecting a metric for profiling. Use
--query-metrics-mode suffix --metrics <metrics list>
to see the full names for the chosen metrics.Some additional metrics do not follow this structured naming. They are documented in the Metrics Reference.
Changing command line output
By default, a temporary file is used to store profiling results, and data is printed to the command line. To permanently store the profiler report, use
-o
to specify the output filename.Besides storing results in a report file, the command line profiler can print results using different pages. Those pages correspond to the respective pages in the UI’s report. By default, the Details page is printed, if no explicit output file is specified. To select a different page or print in addition to storing in an explicit file, use the
--page=<Page>
command. Currently, the following pages are supported:details, raw, source
.Use
--csv
to make any output comma separated and easier to process further. See Console Output for further options, e.g. summary views.Open the report in the UI
The UI executable is called ncu-ui. A shortcut with this name is located in the base directory of the NVIDIA Nsight Compute installation. The actual executable is located in the folder
host\windows-desktop-win7-x64
on Windows orhost/linux-desktop-glibc_2_11_3-x64
on Linux. In the UI window, close the Start Activity dialog and open the report file through File > Open, by dragging the report file into NVIDIA Nsight Compute.You can also specify the report file as a command line parameter to the executable, i.e. as
ncu-ui <MyReport.ncu-rep>
. Alternatively, when using NVIDIA Nsight Compute CLI on a platform with host support,--open-in-ui
can be used directly with ncu to open a collected report in the user interface.The report opens in a new document window. For more information about the report, see the Profiler Report for collecting profile information through NVIDIA Nsight Compute.
4.3. Usage
4.3.1. Modes
Modes change the fundamental behavior of the command line profiler. Depending on which mode is chosen, different Command Line Options become available. For example, Launch is invalid if the Attach mode is selected.
Launch-and-attach: The target application is launched on the local system with the tool’s injection libraries. Depending on which profiling options are chosen, selected kernels in the application are profiled and the results printed to the console or stored in a report file. The tool exits once the target application finishes or crashes, and once all results are processed.
This is the default, and the only mode that supports profiling of child processes on selected platforms.
Launch: The target application is launched on the local system with the tool’s injection libraries. As soon as the first intercepted API call is reached (commonly
cuInit()
), all application threads are suspended. The application now expects a tool to attach for profiling. You can attach using NVIDIA Nsight Compute or using the command line profiler’s Attach mode.Attach: The tool tries to connect to a target application previously launched using NVIDIA Nsight Compute or using the command line profiler’s Launch mode. The tool can attach to a target on the local system or using a remote connection.
4.3.2. Multi-Process Support
NVIDIA Nsight Compute CLI supports profiling multi-process applications on the following platforms: x86_64 Windows, x86_64 Linux, DRIVE OS Linux, DRIVE OS QNX, PowerPC. See the Launch options on how to enable this feature.
On x86_64 Windows, NVIDIA Nsight Compute CLI supports profiling 64-bit processes launched from 32-bit applications by default . On x86_64 Linux, launching from 32-bit applications requires you to enable the support-32bit
option, and the required 32-bit libraries must be installed on your system. On DRIVE OS Linux, DRIVE OS QNX and PowerPC, tracking of 32-bit applications is not supported. Profiling of 32-bit processes is not supported on any platform.
NVIDIA Nsight Compute CLI can be used to profile applications launched with the mpirun
command.
To profile all ranks on a node and store all the profiling data in a single report file:
ncu --target-processes all -o <report-name> mpirun [mpi arguments] <app> [app arguments]
To profile multi-node submissions, one instance of NVIDIA Nsight Compute CLI can be used per node. Ensure that you specify unique report files per rank.
mpirun [mpi arguments] ncu -o report_%q{OMPI_COMM_WORLD_RANK} <app> [app arguments]
To profile a single rank one can use a wrapper script. The following script (called “wrap.sh”) profiles rank 0 only:
#!/bin/bash if [[ $OMPI_COMM_WORLD_RANK == 0 ]]; then ncu -o report_${OMPI_COMM_WORLD_RANK} --target-processes all "$@" else "$@" fi
and then execute:
mpirun [mpi arguments] ./wrap.sh <app> [app arguments]
4.3.3. Output Pages
The command line profiler supports printing results to the console using various pages. Each page has an equivalent in NVIDIA Nsight Compute’s Profiler Report. In the command line profiler, they are slightly adapted to fit console output. To select a page, use the --page
option. By default, the details page is used. Note that if --page
is not used but --export
is, no results will be printed to the console.
Details: This page represents NVIDIA Nsight Compute’s Details page. For every profiled kernel launch, each collected is printed as section as a three-column table, followed by any rule results applied to this section. Rule results not associated with any section are printed after the kernel’s sections.
The first section table column shows the metric name. If the metric was given a label in the section, it is used instead. The second column shows the metric unit, if available. The third column shows the unit value. Both metric unit and value are automatically adjusted to the most fitting order of magnitude. By default, only metrics defined in section headers are shown. This can be changed by passing the
--details-all
option on the command line.Some metrics will show multiple values, separated by “;”, e.g. memory_l2_transactions_global Kbytes 240; 240; 240; 240; 240. Those are instanced metrics, which have one value per represented instance. An instance can be a streaming multiprocessor, an assembly source line, etc.
Raw: This page represents NVIDIA Nsight Compute’s Raw page. For every profiled kernel launch, each collected metric is printed as a three-column table. Besides metrics from sections, this includes automatically collected metrics such as device attributes and kernel launch information.
The first column shows the metric name. The second and third columns show the metric unit and value, respectively. Both metric unit and value are automatically adjusted to the most fitting order of magnitude. No unresolved regex:, group:, or breakdown: metrics are included.
4.3.4. Profile Import
Using the --import
option, saved reports can be imported into the command line profiler. When using this flag, most other options are not available, except for certain result filterting options. They are marked as such in the Profile options table.
4.3.5. Filtered Profile Export
Using the --import
and --export
options together, along with supported filtering options, you can export desired results from one report to another.
Most of the filtering Profile options that can be used with --import
alone are also supported here, except for --metrics
and --section
.
4.3.6. Metrics and Units
When available and applicable, metrics are shown along with their unit. This is to make it apparent if a metric represents cycles, threads, bytes/s, and so on.
By default, units are scaled automatically so that metric values are shown with a reasonable order of magnitude. Units are scaled using their SI-factors, i.e. byte-based units are scaled using a factor of 1000 and the prefixes K, M, G, etc. Time-based units are also scaled using a factor of 1000, with the prefixes n, u and m. This scaling can be changed using a command line option, see Console Output options for details.
4.3.7. NVTX Filtering
--nvtx-include <configuration> --nvtx-exclude <configuration>
You can use both options multiple times, mentioning all the --nvtx-include
configurations followed by all --nvtx-exclude
configurations. NVTX filtering requires --nvtx
option.
NVTX ranges are of two types: NvtxRangeStart/End and NvtxRangePush/Pop. The configuration syntax for both the types are briefly described below. Both range and domain names can contain whitespace. Note that “Domain” and “range” in below example are for illustration purposes only and are not required to mark domain or range names.
Push-Pop Ranges
Quantifier
Description
Example
/
Delimiter between range names. When only a single range name is given, the delimiter must be appended to indicate that this refers to a push/pop range.
A_range/
A_range/B range
A_range/\*/B range
[
Range is at the bottom of the stack
[A_range
[A_range/+/Range Z
]
Range is at the top of the stack
Range Z]
Range C/\*/Range Z]
Only one B rangeetween the two other ranges
B range/+/Range D
*
Zero or more range(s) between the two other ranges
B range/\*/Range Z
@
Specify domain name. If not mentioned, assuming <default domain>
Domain-A@A_range
Domain B@A_range/\*/Range Z]
Include kernels wrapped inside push/pop range ‘A_range’ of ‘<default-domain>’:
ncu --nvtx --nvtx-include "A_range/" CuNvtx.exe
Include kernels wrapped inside push/pop range ‘A_range’ of ‘Domain-A’:
ncu --nvtx --nvtx-include "Domain-A@A_range/" CuNvtx.exe
Include kernels wrapped inside push/pop range ‘A_range’ of ‘<default domain>’, where ‘A_range’ is at the bottom of the stack:
ncu --nvtx --nvtx-include "[A_range" CuNvtx.exe
Include kernels wrapped inside push/pop ranges ‘A_range’ and ‘B range’ of ‘<default domain>’, with zero or many ranges between them:
ncu --nvtx --nvtx-include "A_range/*/B range" CuNvtx.exe
Exclude kernels wrapped inside push/pop ranges ‘A_range’ and ‘B range’ of ‘<default domain>’, with zero or many ranges between them:
ncu --nvtx --nvtx-exclude "A_range/*/B range" CuNvtx.exe
Include kernels wrapped inside only push/pop range ‘A_range’ of ‘<default domain>’ but not inside ‘B range’ at the top of the stack:
ncu --nvtx --nvtx-include "A_range/" --nvtx-exclude "B range]" CuNvtx.exe
Start-End Ranges
Quantifier
Description
Example
,
Delimiter between range names
A_range,B range
B range,A_range,Range C
@
Specify domain name. If not mentioned, assuming <default domain>
Domain-A@A_range
Domain B@B range,Range Z
Include kernels wrapped inside start/end range ‘A_range’ of ‘Domain-A’:
ncu --nvtx --nvtx-include "Domain-A@A_range" CuNvtx.exe
Include kernels wrapped inside both start/end ranges, ‘A_range’ and ‘B range’ of ‘<default domain>’:
ncu --nvtx --nvtx-include "A_range,B range" CuNvtx.exe
Include kernels wrapped inside start/end ranges, ‘A_range’ or ‘B range’ of ‘<default domain>’:
ncu --nvtx --nvtx-include "A_range" --nvtx-include "B range" CuNvtx.exe
Include all kernels, except those which are wrapped inside start/end range ‘A_range’ of ‘<default domain>’:
ncu --nvtx --nvtx-exclude "A_range" CuNvtx.exe
Include kernels wrapped inside only start/end ‘B range’ and not ‘A_range’ of ‘<default domain>’:
ncu --nvtx --nvtx-include "B range"--nvtx-exclude "A_range" CuNvtx.exe
Regular Expression Support
The configuration syntax for both the types NvtxRangeStart/End and NvtxRangePush/Pop is the same. Additionally, to use regular expressions, follow the following syntax.
Provide prefix ‘regex:’ to treat nvtx config as regular expression.
ncu --nvtx --nvtx-include "regex:Domain[A-Z]@Range[0-9]/" CuNvtx.exe
The kernels wrapped inside push/pop range with matching regex ‘Range[0-9]’ of domain with matching regex ‘Domain[A-Z]’ are profiled.Provide ‘/’ as a prefix to “[” or “]” only for the range part of the config if “[” or “]” is at the start or at the end of the range part, respectively. This is needed so that NCU can distinguish if “[” or “]” is part of the regex or represents the top/bottom of the stack.
ncu --nvtx --nvtx-include "regex:[0-9]domainA@/[0-9]rangeA,RangeC[0-9/]" CuNvtx.exe
The kernels wrapped inside start/end ranges with matching regex ‘[0-9]rangeA’ and ‘RangeC[0-9]’ of domain with matching regex ‘[0-9]domainA’ are profiled.If any quantifier is part of the domain/range name, you need to use ‘\\’ or ‘\’ as a prefix. For the “$” quantifier, only the ‘\\’ prefix is valid.
Additional Information
--nvtx-include "DomainA@RangeA,DomainB@RangeB" //Not a valid config
In a single NVTX configuration, multiple ranges with regard to a single domain can be specified. Mentioning ranges from different domains inside a single NVTX config is not supported.
--nvtx-include "A_range\[i\]"
Quantifiers
@ , [ ] / * +
, including regular expression quantifiers, can be used in domain/range names using prefix ‘\’. The kernels wrapped inside ‘A_range[i]’ of ‘<default domain>’ in the application are profiled.--nvtx-include "A_range" //Start/End configuration --nvtx-inlcude "A_range/" //Push/Pop configuration --nvtx-inlcude "A_range]" //Push/Pop configuration
If the domain/range name contains ‘\’, you need to provide ‘\\\\’ in the config.
Do not use ‘\\\\’ before any quantifier.
Including/Excluding only single range for Push/Pop configuration without specifying stack frame position ‘[’ or ‘]’, use ‘/’ quantifier at the end.
--nvtx-include "A_range/*/B range"
The order in which you mention Push/Pop configurations is important. In the above example, ‘A_range’ should be below ‘B range’ in the stack of ranges so that the kernel is profiled.
NVTX filtering honors cudaProfilerStart() and cudaProfilerStop(). There is no support for ranges with no name.
4.3.8. Config File
--config-file on/off
option, parsing parameters from config file can be enabled or disabled.--config-file-path <path>
option, default path and name of config file can be overwritten.config.ncu-cfg
is searched in the current working directory, $HOME/.config/NVIDIA Corporation
on Linux and %APPDATA%\NVIDIA Corporation\
on Windows. If a valid config file is found, ncu parses the file and initializes any command line parameters to the values set in the file. If the same command line parameter is also set explicitly during the current invocation, the latter takes precedence.Parameters can be set under various general modes and ncu command line parameters are used to determine which general-mode needs to be parsed from the config file. See the table below for more details.
Command line parameters |
General Mode |
---|---|
ncu –mode launch-and-attach CuVectorAddMulti.exe |
Launch-and-attach |
ncu –mode launch CuVectorAddMulti.exe |
Launch |
ncu –mode attach |
Attach |
ncu –list-sets, ncu –list-sections, ncu –list-rules and ncu –list-metrics |
List |
ncu –query-metrics |
Query |
ncu -i <MyReport.ncu-rep> |
Import |
These general modes should be defined in the config file using INI-like syntax as:
[<general-mode>]
<parameter>=<value>
;<comments>
Sample usage
[Launch-and-attach]
-c = 1
--section = LaunchStats, Occupancy
[Import]
--open-in-ui
-c = 1
--section = LaunchStats, Occupancy
From this configuration, ncu will parse parameters set under [Launch-and-attach]
block whenever an application is profiled in launch-and-attach
mode. In the same manner, parameters set under [Import]
block will be parsed whenever a report is imported. Different modes can be clubbed together if there exists a set of parameters which is common to each mode. Sample shown above can be rewritten after clubbing both modes as:
[Launch-and-attach, import]
-c = 1
--section = LaunchStats, Occupancy
[Import]
--open-in-ui
Additional points
Options like
--open-in-ui
do not expect any value to be set. These options should not be passed any value.Options like
--section
can be passed multiple times in the command line. These options should be written only once under a general-mode with all required values seperated by comma as shown below. Explicitly setting values for these options will not overwrite the config file values. Instead, all values will be composed together and set to the option.[<general-mode>] <parameter>=<value1>,<value2>,...
4.3.9. Kernel Renaming
In some cases, it gets difficult to distinguish between results using the kernel function or mangled name.
However, demangled names can be quite long and complex to understand. To handle such cases, kernel demangled names are auto-simplified to some extent.
To see original kernel demangled names, disable kernel renaming using --rename-kernels off
option.
If a simplified kernel demangled name turns out to be not useful, you can rename it through the configuration file.
A kernel renaming configuration file should be a YAML file written in the following format:
-
- Original: mergeRanksAndIndicesKernel(unsigned int *, unsigned int *, unsigned int, unsigned int, unsigned int)
- Renamed: Merge Rank Kernel
-
- Original: void mergeSortSharedKernel<(unsigned int)1>(unsigned int *, unsigned int *, unsigned int *, unsigned int *, unsigned int)
- Renamed: Merge Sort Kernel
ncu-kernel-renames.yaml
is searched in the similar way as config file is searched.--rename-kernels-export on
option to export demangled names from the report to the config file with mappings for renaming them.--rename-kernels-path <path>
option, default path and name of the file used while importing renamed names and exporting can be overwritten.--kernel-name
and --kernel-id
options.4.4. Command Line Options
For long command line options, passing a unique initial substring can be sufficient.
4.4.1. General
Option |
Description |
Default |
---|---|---|
h,help |
Show help message |
|
v,version |
Show version information |
|
mode |
Select the mode of interaction with the target application
|
launch-and-attach |
p,port |
Base port used for connecting to target applications for |
49152 |
max-connections |
Maximum number of ports for connecting to target applications |
64 |
config-file |
Use config.ncu-cfg config file to set parameters. Searches in the current working directory, in “$HOME/.config/NVIDIA Corporation” on Linux and in “%APPDATA%\NVIDIA Corporation\” on Windows. |
on |
config-file-path |
Override the default path for config file. |
4.4.2. Launch
Option |
Description |
Default |
---|---|---|
check-exit-code |
Check the application exit code and print an error if it is different than 0. If set, |
yes |
injection-path-64 |
Override the default path for the injection libraries. The injection libraries are used by the tools to intercept relevant APIs (like CUDA or NVTX). |
|
preload-library |
Prepend a shared library to be loaded by the application before the injection libraries. This option can be given multiple times and the libraries will be loaded in the order they were specified. |
|
call-stack |
Enable CPU Call Stack collection. |
false |
call-stack-type |
Set the call stack type(s) that should be collected. More than one type may be specified. Implies –call-stack. Note that Python call stack collection requires CPython version 3.9 or later. |
native Examples
|
nvtx |
Enable NVTX support for tools. |
false |
target-processes |
Select the processes you want to profile. Available modes are:
|
all |
target-processes-filter |
Set the comma separated expressions to filter which processes are profiled.
The executable name part of the process will be considered in the match. Processing of filters stops at the first match. If any positive filter is specified, no process that is not matching a positive filter is profiled. |
Examples
|
support-32bit |
Support profiling processes launched from 32-bit applications. This option is only available on x86_64 Linux. On Windows, tracking 32-bit applications is enabled by default. |
no |
null-stdin |
Launch the application with ‘/dev/null’ as its standard input. This avoids applications reading from standard input being stopped by |
false |
4.4.3. Attach
Option |
Description |
Default |
---|---|---|
hostname |
Set the hostname or IP address for connecting to the machine on which the target application is running. When attaching to a local target application, use 127.0.0.1. |
127.0.0.1 |
4.4.4. Profile
Option |
Description |
Default/Examples |
---|---|---|
devices |
List the GPU devices to enable profiling on, separated by comma. 1 |
All devices Examples
|
filter-mode |
Set the filtering mode for kernel launches. Available modes:
|
global |
kernel-id |
Set the identifier to use for matching kernels. If the kernel does not match the identifier, it will be ignored for profiling. The identifier must be of the following format: context-id:stream-id:[name-operator:]kernel-name:invocation-nr
If the context/stream ID is a positive number, it will be strictly matched against the CUDA context/stream ID. Otherwise it will be treated as a regular expression and matched against the context/stream name specified using the NVTX library. 1 |
Examples
|
k,kernel-name |
Set the expression to use when matching kernel names.
If the kernel name or the provided expression do not match, it will be ignored for profiling. 1 |
Examples
|
kernel-name-base |
Set the basis for
|
function |
rename-kernels |
Perform simplification on the kernel demangled names. Rename demangled names using a config file. See Kernel Renaming for more details. |
on |
rename-kernels-export |
Export demangled names from the report to a new file and specify mappings for renaming them. Use |
off |
rename-kernels-path |
Override the default path of the configuration file which should be used while importing renamed kernels or exporting demangled names. Only valid while using |
|
c,launch-count |
Limit the number of profiled kernel launches. The count is only incremented for launches that match the kernel filters.1 |
|
s,launch-skip |
Set the number of kernel launches to skip before starting to profile kernels. The number takes into account only launches that match the kernel filters. 1 |
0 |
launch-skip-before-match |
Set the number of kernel launches to skip before starting to profile. The count is incremented for all launches, regardless of the kernel filters. 1 |
0 |
range-filter |
Filter to profile specified instance(s) of matching NVTX ranges or start/stop ranges created through cu(da)ProfilerStart/Stop APIs. Specify in format [yes/no/on/off]:[start/stop range instance(s)]:[NVTX range instance(s)]
|
Examples
|
kill |
Terminate the target application when the requested –launch-count was profiled. Allowed values:
|
no |
replay-mode |
Mechanism used for replaying a kernel launch multiple times to collect all requested profiling data:
|
kernel |
app-replay-buffer |
Application replay buffer location.
|
file |
app-replay-match |
Application replay kernel matching strategy. For all options, kernels are matched on a per-process and per-device (GPU) basis. Below options are used to configure the applied strategy in more detail.
|
grid |
app-replay-mode |
Application replay kernel matching mode:
|
strict |
range-replay-options |
Range replay options, separated by comma. Below options are supported:
|
none |
graph-profiling |
CUDA graph profiling mode:
|
node |
list-sets |
List all section sets found in the searched section folders and exit. For each set, the associated sections are shown, as well as the estimated number of metrics collected as part of this set. This number can be used as an estimate of the relative profiling overhead per kernel launch of this set. |
|
set |
Identifier of section set to collect. If not specified, the |
If no |
list-sections |
List all sections found in the searched section folders and exit. |
|
section |
Add a section identifier to collect in one of the following ways:
This option is ignored when used with |
If no |
section-folder |
Add a non-recursive search path for |
If no |
section-folder-recursive |
Add a recursive search path for |
If no |
list-rules |
List all rules found in the searched section folders and exit. |
|
apply-rules |
Apply active and applicable rules to each profiling result. Use
|
yes |
rule |
Add a rule identifier to apply. Implies |
If no |
import-source |
If available from -lineinfo, correlated CUDA source files are permanently imported into the report. Allowed values:
Use |
no |
source-folders |
Add comma separated recursive search paths for missing CUDA source files to import into the report. |
|
list-metrics |
List all metrics collected from active sections. If the list of active sections is restricted using the |
|
query-metrics |
Query available metrics for the devices on system. Use |
|
query-metrics-mode |
Set the mode for querying metrics. Implies
|
base |
query-metrics-collection |
Set which metric collection kind to query. Implies
|
profiling |
metrics |
Specify all metrics to be profiled, separated by comma. If no Names passed to this option support the following prefixes:
Combining multiple prefixes is not supported. If a metric requires a suffix to be valid, and neither When importing a report, When using |
|
disable-extra-suffixes |
Disable the collection of extra suffixes (avg, min, max, sum) for all metrics. Only collect what is explicity specified. |
|
list-chips |
List all supported chips that can be used with |
|
chips |
Specify the chips for querying metrics, separated by comma. |
Examples
|
profile-from-start |
Set if application should be profiled from its start. Allowed values:
|
yes |
disable-profiler-start-stop |
Disable profiler start/stop. When enabled, |
|
quiet |
Suppress all profiling output. |
|
verbose |
Make profiler output more verbose. |
|
cache-control |
Control the behavior of the GPU caches during profiling. Allowed values:
|
all |
clock-control |
Control the behavior of the GPU clocks during profiling. Allowed values:
|
base |
nvtx-include |
Adds an include statement to the NVTX filter, which allows selecting kernels to profile based on NVTX ranges. 1 |
|
nvtx-exclude |
Adds an exclude statement to the NVTX filter, which allows selecting kernels to profile based on NVTX ranges. 1 |
4.4.5. PM Sampling
These options apply to PM sampling. See here for options used in warp state sampling.
Option |
Description |
Default |
---|---|---|
pm-sampling-interval |
Set the PM sampling interval in cycles or ns (depending on the architecture), or determine dynamically when 0. |
0 (auto) |
pm-sampling-buffer-size |
Set the size of the device-sided allocation for PM sampling in bytes, or determine dynamically when 0. |
0 (auto) |
pm-sampling-max-passes |
Set the maximum number of passes used for PM sampling, or determine dynamically when 0. |
0 (auto) |
4.4.6. Warp Sampling
Option |
Description |
Default |
---|---|---|
warp-sampling-interval |
Set the sampling period in the range of [0..31]. The actual frequency is 2 ^ (5 + value) cycles. If set to ‘auto’, the profiler tries to automatically determine a high sampling frequency without skipping samples or overflowing the output buffer. |
auto |
warp-sampling-max-passes |
Set maximum number of passes used for sampling (see the Kernel Profiling Guide for more details on profiling overhead). |
5 |
warp-sampling-buffer-size |
Set the size of the device-sided allocation for samples in bytes. |
32*1024*1024 |
4.4.7. File
Option |
Description |
Default |
---|---|---|
log-file |
Send all tool output to the specified file, or one of the standard channels. The file will be overwritten. If the file doesn’t exist, a new one will be created.”stdout” as the whole file name indicates standard output channel (stdout). “stderr” as the whole file name indicates standard error channel (stderr).” |
If |
o,export |
Set the output file for writing the profile report. If not set, a temporary file will be used which is removed afterwards. Use with |
If |
f,force-overwrite |
Force overwriting all output files. |
By default, the profiler won’t overwrite existing output files and show an error instead. |
i,import |
Set the input file for reading the profile results. |
|
open-in-ui |
Open report in UI instead of showing result on terminal. (Only available on host platforms) |
|
section-folder-restore |
Restores stock files to the default section folder or the folder specified by an accompanying –section-folder option. If the operation will overwrite modified files then the –force-overwrite option is required. |
4.4.8. Console Output
Option |
Description |
Default |
---|---|---|
csv |
Use comma-separated values as console output. Implies –print-units base by default. |
|
page |
Select the report page to print console output for. Available pages are:
|
details. If no |
print-source |
Select the source view:
Metric correlation with source is available in sass, and cuda,sass source view. Metrics specified with |
sass |
resolve-source-file |
Resolve CUDA source file in the |
|
print-details |
Select which part of a section should be shown in the details page output:
Replaces deprecated option |
header |
print-metric-name |
Select one of the option to show it in the Metric Name column:
|
label |
print-units |
Select the mode for scaling of metric units. Available modes are:
|
auto |
print-metric-attribution |
Show the attribution level for metrics of Green Context results. |
false |
print-fp |
Show all numeric metrics in the console output as floating point numbers. |
false |
print-kernel-base |
Set the basis for kernel name output. See |
demangled |
print-metric-instances |
Set output mode for metrics with instance values:
|
none |
print-nvtx-rename |
Select how NVTX should be used for renaming:
|
none |
print-rule-details |
Print additional details for rule results, such as the triggering metrics. Currently has no effect in CSV mode. |
false |
print-summary |
Select the summary output mode. Available modes are:
|
none |
4.4.9. Response File
Response files can be specified by adding @FileName
to the command line. The file name must immediately follow the @
character. The content of each response file is inserted in place of the corresponding response file option.
4.4.10. File Macros
The file name specified with option -o
or --export
supports the following macro expansions. Occurrences of these macros in the report file name are replaced by the corresponding character sequence. If not specified otherwise, the macros cannot be used as part of the file path.
Macro |
Description |
---|---|
%h |
Expands to the host name of the machine on which the command line profiler is running. |
%q{ENV_NAME} |
Expands to the content of the variable with the given name |
%p |
Expands to the process ID of the command line profiler. |
%i |
Expands to the lowest unused positive integer number that guarantees the resulting file name is not yet used. This macro can only be used once in the output file name. |
%% |
Expands to a single |
4.5. Environment Variables
The following environment variables can be set before launching NVIDIA Nsight Compute CLI, or the UI, respectively.
Name |
Description |
Default/Values |
---|---|---|
NV_COMPUTE_PROFILER_DISABLE_STOCK_FILE_DEPLOYMENT |
Disable file deployment to the versioned By default, the versioned directory from the user’s documents folder is used to ensure that any potential user updates are taken into account. Only supported in the NVIDIA Nsight Compute CLI. |
Default: unset Set to “1” to disable deployment. |
NV_COMPUTE_PROFILER_LOCAL_CONNECTION_OVERRIDE |
Override the default local connection mechanism between frontend and profiled target processes. The default mechanism is platform-dependent. This should only be used if there are connection problems between frontend and target processes in a local launch. |
Default: unset (use default mechanism) Set to “uds” to use Unix Domain Socket connections (available on Posix platforms, only). Set to “tcp” to use TCP (available on all platforms). Set to “named-pipes” to use Windows Named Pipes (available on Windows, only). |
NV_COMPUTE_PROFILER_DISABLE_SW_PRE_PASS |
Disable the instruction-level software (SW) metric pre-pass. When collecting SW-patched metrics, such as |
Default: unset (use pre-pass when applicable) Set to “1” to disable pre-pass. |
4.6. Nvprof Transition Guide
This guide provides tips for moving from nvprof to NVIDIA Nsight Compute CLI. NVIDIA Nsight Compute CLI tries to provide as much feature and usage parity as possible with nvprof, but some features are now covered by different tools and some command line options have changed their name or meaning.
4.6.1. Trace
GPU and API trace
NVIDIA Nsight Compute CLI does not support any form of tracing GPU or API activities. This functionality is covered by NVIDIA Nsight Systems.
4.6.2. Metric Collection
Finding available metrics
For nvprof, you can use
--query-metrics
to see the list of metrics available for the current devices on your machine. You can also use--devices
to filter which local devices to query. For NVIDIA Nsight Compute CLI, this functionality is the same. However, in addition, you can combine--query-metrics
with--chip [chipname]
to query the available metrics for any chip, not only the ones in your present CUDA devices.Note that metric names have changed between nvprof and NVIDIA Nsight Compute CLI and metric names also differ between chips after (and including) GV100 and those before. See Metric Comparison for a comparison of nvprof and NVIDIA Nsight Compute metric names.
On Volta and newer GPUs, most metrics are named using a base name and various suffixes, e.g. sm__throughput.avg.pct_of_peak_sustained_elapsed. The base name is sm__throughput and the suffix is avg.pct_of_peak_sustained_elapsed. This is because most metrics follow the same structure and have the same set of suffixes. You need to pass the full name to NVIDIA Nsight Compute when selecting a metric for profiling.
To reduce the number of metrics shown for Volta and newer GPUs when using
--query-metrics
, by default only the base names are shown. Use--query-metrics-mode suffix --metrics <metrics list>
to see the full names for the chosen metrics. Use--query-metrics-mode all
to see all metrics with their full name directly.Selecting which metrics to collect
In both nvprof and NVIDIA Nsight Compute CLI, you can specify a comma-separated list of metric names to the
--metrics
option. While nvprof would allow you to collect either a list or all metrics, in NVIDIA Nsight Compute CLI you can use regular expressions to select a more fine-granular subset of all available metrics. For example, you can use--metrics "regex:.*"
to collect all metrics, or--metrics "regex:smsp__cycles_elapsed"
to collect all “smsp__cycles_elapsed” metrics.Selecting which events to collect
You cannot collect any events in NVIDIA Nsight Compute CLI.
Selecting which section to collect
In nvprof, you can either collect individual metrics or events, or a pre-configured set (all, analysis-metrics). NVIDIA Nsight Compute CLI adds the concept of a section. A section is a file that describes which metrics to collect for which GPU architecture, or architecture range. Furthermore, it defines how those metrics will be shown in both the command line output or the user interface. This includes structuring in tables, charts, histograms etc.
NVIDIA Nsight Compute CLI comes with a set of pre-defined sections, located in the
sections
directory. You can inspect, modify or extend those, as well as add new ones, e.g. to easily collect recurring metric sets. Each section specifies a unique section identifier, and there must not be two sections with the same identifier in the search path.By default, the sections associated with the
basic
section set are collected. You can select one or more individual sections using the--section [section identifier]
option one or more times. If no--section
option is given, but--metrics
is used, no sections will be collected.Selecting which section set to collect
In nvprof, you can either collect individual metrics or events, or a pre-configured set (all, analysis-metrics). NVIDIA Nsight Compute CLI adds the concept of section sets. A section set defines a group of sections to collect together, in order to achieve different profiling overheads, depending on the required analysis level of detail.
If no other options are selected, the
basic
section set is collected. You can select one or more sets using the--set [set identifier]
option one or more times. If no--set
option is given, but--section
or--metrics
is used, no sets will be collected.
4.6.3. Metric Comparison
NVIDIA Nsight Compute uses two groups of metrics, depending on which GPU architecture is profiled. For nvprof metrics, the following table lists the equivalent metrics in NVIDIA Nsight Compute, if available. For a detailed explanation of the structuring of PerfWorks metrics, see Metrics Structure.
Metrics starting with sm__& are collected per-SM. Metrics starting with *smsp__ are collected per-SM subpartition. However, all corresponding nvprof events are collected per-SM, only. Check the Metrics Guide for more details on these terms.
nvprof Metric |
PerfWorks Metric or Formula (>= SM 7.0) |
---|---|
achieved_occupancy |
sm__warps_active.avg.pct_of_peak_sustained_active |
atomic_transactions |
l1tex__t_set_accesses_pipe_lsu_mem_global_op_atom.sum + l1tex__t_set_accesses_pipe_lsu_mem_global_op_red.sum |
atomic_transactions_per_request |
(l1tex__t_sectors_pipe_lsu_mem_global_op_atom.sum + l1tex__t_sectors_pipe_lsu_mem_global_op_red.sum) / (l1tex__t_requests_pipe_lsu_mem_global_op_atom.sum + l1tex__t_requests_pipe_lsu_mem_global_op_red.sum) |
branch_efficiency |
smsp__sass_average_branch_targets_threads_uniform.pct |
cf_executed |
smsp__inst_executed_pipe_cbu.sum + smsp__inst_executed_pipe_adu.sum |
cf_fu_utilization |
n/a |
cf_issued |
n/a |
double_precision_fu_utilization |
smsp__inst_executed_pipe_fp64.avg.pct_of_peak_sustained_active |
dram_read_bytes |
dram__bytes_read.sum |
dram_read_throughput |
dram__bytes_read.sum.per_second |
dram_read_transactions |
dram__sectors_read.sum |
dram_utilization |
dram__throughput.avg.pct_of_peak_sustained_elapsed |
dram_write_bytes |
dram__bytes_write.sum |
dram_write_throughput |
dram__bytes_write.sum.per_second |
dram_write_transactions |
dram__sectors_write.sum |
eligible_warps_per_cycle |
smsp__warps_eligible.sum.per_cycle_active |
flop_count_dp |
smsp__sass_thread_inst_executed_op_dadd_pred_on.sum + smsp__sass_thread_inst_executed_op_dmul_pred_on.sum + smsp__sass_thread_inst_executed_op_dfma_pred_on.sum * 2 |
flop_count_dp_add |
smsp__sass_thread_inst_executed_op_dadd_pred_on.sum |
flop_count_dp_fma |
smsp__sass_thread_inst_executed_op_dfma_pred_on.sum |
flop_count_dp_mul |
smsp__sass_thread_inst_executed_op_dmul_pred_on.sum |
flop_count_hp |
smsp__sass_thread_inst_executed_op_hadd_pred_on.sum + smsp__sass_thread_inst_executed_op_hmul_pred_on.sum + smsp__sass_thread_inst_executed_op_hfma_pred_on.sum * 2 |
flop_count_hp_add |
smsp__sass_thread_inst_executed_op_hadd_pred_on.sum |
flop_count_hp_fma |
smsp__sass_thread_inst_executed_op_hfma_pred_on.sum |
flop_count_hp_mul |
smsp__sass_thread_inst_executed_op_hmul_pred_on.sum |
flop_count_sp |
smsp__sass_thread_inst_executed_op_fadd_pred_on.sum + smsp__sass_thread_inst_executed_op_fmul_pred_on.sum + smsp__sass_thread_inst_executed_op_ffma_pred_on.sum * 2 |
flop_count_sp_add |
smsp__sass_thread_inst_executed_op_fadd_pred_on.sum |
flop_count_sp_fma |
smsp__sass_thread_inst_executed_op_ffma_pred_on.sum |
flop_count_sp_mul |
smsp__sass_thread_inst_executed_op_fmul_pred_on.sum |
flop_count_sp_special |
n/a |
flop_dp_efficiency |
smsp__sass_thread_inst_executed_ops_dadd_dmul_dfma_pred_on.avg.pct_of_peak_sustained_elapsed |
flop_hp_efficiency |
smsp__sass_thread_inst_executed_ops_hadd_hmul_hfma_pred_on.avg.pct_of_peak_sustained_elapsed |
flop_sp_efficiency |
smsp__sass_thread_inst_executed_ops_fadd_fmul_ffma_pred_on.avg.pct_of_peak_sustained_elapsed |
gld_efficiency |
smsp__sass_average_data_bytes_per_sector_mem_global_op_ld.pct |
gld_requested_throughput |
n/a |
gld_throughput |
l1tex__t_bytes_pipe_lsu_mem_global_op_ld.sum.per_second |
gld_transactions |
l1tex__t_sectors_pipe_lsu_mem_global_op_ld.sum |
gld_transactions_per_request |
l1tex__average_t_sectors_per_request_pipe_lsu_mem_global_op_ld.ratio |
global_atomic_requests |
l1tex__t_requests_pipe_lsu_mem_global_op_atom.sum |
global_hit_rate |
(l1tex__t_sectors_pipe_lsu_mem_global_op_ld_lookup_hit.sum + l1tex__t_sectors_pipe_lsu_mem_global_op_st_lookup_hit.sum + l1tex__t_sectors_pipe_lsu_mem_global_op_red_lookup_hit.sum + l1tex__t_sectors_pipe_lsu_mem_global_op_atom_lookup_hit.sum) / (l1tex__t_sectors_pipe_lsu_mem_global_op_ld.sum + l1tex__t_sectors_pipe_lsu_mem_global_op_st.sum + l1tex__t_sectors_pipe_lsu_mem_global_op_red.sum + l1tex__t_sectors_pipe_lsu_mem_global_op_atom.sum) |
global_load_requests |
l1tex__t_requests_pipe_lsu_mem_global_op_ld.sum |
global_reduction_requests |
l1tex__t_requests_pipe_lsu_mem_global_op_red.sum |
global_store_requests |
l1tex__t_requests_pipe_lsu_mem_global_op_st.sum |
gst_efficiency |
smsp__sass_average_data_bytes_per_sector_mem_global_op_st.pct |
gst_requested_throughput |
n/a |
gst_throughput |
l1tex__t_bytes_pipe_lsu_mem_global_op_st.sum.per_second |
gst_transactions |
l1tex__t_sectors_pipe_lsu_mem_global_op_st.sum |
gst_transactions_per_request |
l1tex__average_t_sectors_per_request_pipe_lsu_mem_global_op_st.ratio |
half_precision_fu_utilization |
smsp__inst_executed_pipe_fp16.avg.pct_of_peak_sustained_active |
inst_bit_convert |
smsp__sass_thread_inst_executed_op_conversion_pred_on.sum |
inst_compute_ld_st |
smsp__sass_thread_inst_executed_op_memory_pred_on.sum |
inst_control |
smsp__sass_thread_inst_executed_op_control_pred_on.sum |
inst_executed |
smsp__inst_executed.sum |
inst_executed_global_atomics |
smsp__sass_inst_executed_op_global_atom.sum |
inst_executed_global_loads |
smsp__inst_executed_op_global_ld.sum |
inst_executed_global_reductions |
smsp__inst_executed_op_global_red.sum |
inst_executed_global_stores |
smsp__inst_executed_op_global_st.sum |
inst_executed_local_loads |
smsp__inst_executed_op_local_ld.sum |
inst_executed_local_stores |
smsp__inst_executed_op_local_st.sum |
inst_executed_shared_atomics |
smsp__inst_executed_op_shared_atom.sum + smsp__inst_executed_op_shared_atom_dot_alu.sum + smsp__inst_executed_op_shared_atom_dot_cas.sum |
inst_executed_shared_loads |
smsp__inst_executed_op_shared_ld.sum |
inst_executed_shared_stores |
smsp__inst_executed_op_shared_st.sum |
inst_executed_surface_atomics |
smsp__inst_executed_op_surface_atom.sum |
inst_executed_surface_loads |
smsp__inst_executed_op_surface_ld.sum + smsp__inst_executed_op_shared_atom_dot_alu.sum + smsp__inst_executed_op_shared_atom_dot_cas.sum |
inst_executed_surface_reductions |
smsp__inst_executed_op_surface_red.sum |
inst_executed_surface_stores |
smsp__inst_executed_op_surface_st.sum |
inst_executed_tex_ops |
smsp__inst_executed_op_texture.sum |
inst_fp_16 |
smsp__sass_thread_inst_executed_op_fp16_pred_on.sum |
inst_fp_32 |
smsp__sass_thread_inst_executed_op_fp32_pred_on.sum |
inst_fp_64 |
smsp__sass_thread_inst_executed_op_fp64_pred_on.sum |
inst_integer |
smsp__sass_thread_inst_executed_op_integer_pred_on.sum |
inst_inter_thread_communication |
smsp__sass_thread_inst_executed_op_inter_thread_communication_pred_on.sum |
inst_issued |
smsp__inst_issued.sum |
inst_misc |
smsp__sass_thread_inst_executed_op_misc_pred_on.sum |
inst_per_warp |
smsp__average_inst_executed_per_warp.ratio |
inst_replay_overhead |
n/a |
ipc |
smsp__inst_executed.avg.per_cycle_active |
issue_slot_utilization |
smsp__issue_active.avg.pct_of_peak_sustained_active |
issue_slots |
smsp__inst_issued.sum |
issued_ipc |
smsp__inst_issued.avg.per_cycle_active |
l2_atomic_throughput |
2 * ( lts__t_sectors_op_atom.sum.per_second + lts__t_sectors_op_red.sum.per_second ) |
l2_atomic_transactions |
2 * ( lts__t_sectors_op_atom.sum + lts__t_sectors_op_red.sum ) |
l2_global_atomic_store_bytes |
lts__t_bytes_equiv_l1sectormiss_pipe_lsu_mem_global_op_atom.sum |
l2_global_load_bytes |
lts__t_bytes_equiv_l1sectormiss_pipe_lsu_mem_global_op_ld.sum |
l2_local_global_store_bytes |
lts__t_bytes_equiv_l1sectormiss_pipe_lsu_mem_local_op_st.sum + lts__t_bytes_equiv_l1sectormiss_pipe_lsu_mem_global_op_st.sum |
l2_local_load_bytes |
lts__t_bytes_equiv_l1sectormiss_pipe_lsu_mem_local_op_ld.sum |
l2_read_throughput |
lts__t_sectors_op_read.sum.per_second + lts__t_sectors_op_atom.sum.per_second + lts__t_sectors_op_red.sum.per_second 2 |
l2_read_transactions |
lts__t_sectors_op_read.sum + lts__t_sectors_op_atom.sum + lts__t_sectors_op_red.sum 2 |
l2_surface_load_bytes |
lts__t_bytes_equiv_l1sectormiss_pipe_tex_mem_surface_op_ld.sum |
l2_surface_store_bytes |
lts__t_bytes_equiv_l1sectormiss_pipe_tex_mem_surface_op_st.sum |
l2_tex_hit_rate |
lts__t_sector_hit_rate.pct |
l2_tex_read_hit_rate |
lts__t_sector_op_read_hit_rate.pct |
l2_tex_read_throughput |
lts__t_sectors_srcunit_tex_op_read.sum.per_second |
l2_tex_read_transactions |
lts__t_sectors_srcunit_tex_op_read.sum |
l2_tex_write_hit_rate |
lts__t_sector_op_write_hit_rate.pct |
l2_tex_write_throughput |
lts__t_sectors_srcunit_tex_op_write.sum.per_second |
l2_tex_write_transactions |
lts__t_sectors_srcunit_tex_op_write.sum |
l2_utilization |
lts__t_sectors.avg.pct_of_peak_sustained_elapsed |
l2_write_throughput |
lts__t_sectors_op_write.sum.per_second + lts__t_sectors_op_atom.sum.per_second + lts__t_sectors_op_red.sum.per_second |
l2_write_transactions |
lts__t_sectors_op_write.sum + lts__t_sectors_op_atom.sum + lts__t_sectors_op_red.sum |
ldst_executed |
n/a |
ldst_fu_utilization |
smsp__inst_executed_pipe_lsu.avg.pct_of_peak_sustained_active |
ldst_issued |
n/a |
local_hit_rate |
n/a |
local_load_requests |
l1tex__t_requests_pipe_lsu_mem_local_op_ld.sum |
local_load_throughput |
l1tex__t_bytes_pipe_lsu_mem_local_op_ld.sum.per_second |
local_load_transactions |
l1tex__t_sectors_pipe_lsu_mem_local_op_ld.sum |
local_load_transactions_per_request |
l1tex__average_t_sectors_per_request_pipe_lsu_mem_local_op_ld.ratio |
local_memory_overhead |
n/a |
local_store_requests |
l1tex__t_requests_pipe_lsu_mem_local_op_st.sum |
local_store_throughput |
l1tex__t_sectors_pipe_lsu_mem_local_op_st.sum.per_second |
local_store_transactions |
l1tex__t_sectors_pipe_lsu_mem_local_op_st.sum |
local_store_transactions_per_request |
l1tex__average_t_sectors_per_request_pipe_lsu_mem_local_op_st.ratio |
nvlink_data_receive_efficiency |
n/a |
nvlink_data_transmission_efficiency |
n/a |
nvlink_overhead_data_received |
(nvlrx__bytes_data_protocol.sum / nvlrx__bytes.sum) * 100 |
nvlink_overhead_data_transmitted |
(nvltx__bytes_data_protocol.sum / nvltx__bytes.sum) * 100 |
nvlink_receive_throughput |
nvlrx__bytes.sum.per_second |
nvlink_total_data_received |
nvlrx__bytes.sum |
nvlink_total_data_transmitted |
nvltx__bytes.sum |
nvlink_total_nratom_data_transmitted |
n/a |
nvlink_total_ratom_data_transmitted |
n/a |
nvlink_total_response_data_received |
n/a |
nvlink_total_write_data_transmitted |
n/a |
nvlink_transmit_throughput |
nvltx__bytes.sum.per_second |
nvlink_user_data_received |
nvlrx__bytes_data_user.sum |
nvlink_user_data_transmitted |
nvltx__bytes_data_user.sum |
nvlink_user_nratom_data_transmitted |
n/a |
nvlink_user_ratom_data_transmitted |
n/a |
nvlink_user_response_data_received |
n/a |
nvlink_user_write_data_transmitted |
n/a |
pcie_total_data_received |
pcie__read_bytes.sum |
pcie_total_data_transmitted |
pcie__write_bytes.sum |
shared_efficiency |
smsp__sass_average_data_bytes_per_wavefront_mem_shared.pct |
shared_load_throughput |
l1tex__data_pipe_lsu_wavefronts_mem_shared_op_ld.sum.per_second |
shared_load_transactions |
l1tex__data_pipe_lsu_wavefronts_mem_shared_op_ld.sum |
shared_load_transactions_per_request |
n/a |
shared_store_throughput |
l1tex__data_pipe_lsu_wavefronts_mem_shared_op_st.sum.per_second |
shared_store_transactions |
l1tex__data_pipe_lsu_wavefronts_mem_shared_op_st.sum |
shared_store_transactions_per_request |
n/a |
shared_utilization |
l1tex__data_pipe_lsu_wavefronts_mem_shared.avg.pct_of_peak_sustained_elapsed |
single_precision_fu_utilization |
smsp__pipe_fma_cycles_active.avg.pct_of_peak_sustained_active |
sm_efficiency |
smsp__cycles_active.avg.pct_of_peak_sustained_elapsed |
sm_tex_utilization |
l1tex__texin_sm2tex_req_cycles_active.avg.pct_of_peak_sustained_elapsed |
special_fu_utilization |
smsp__inst_executed_pipe_xu.avg.pct_of_peak_sustained_active |
stall_constant_memory_dependency |
smsp__warp_issue_stalled_imc_miss_per_warp_active.pct |
stall_exec_dependency |
smsp__warp_issue_stalled_short_scoreboard_per_warp_active.pct + smsp__warp_issue_stalled_wait_per_warp_active.pct |
stall_inst_fetch |
smsp__warp_issue_stalled_no_instruction_per_warp_active.pct |
stall_memory_dependency |
smsp__warp_issue_stalled_long_scoreboard_per_warp_active.pct |
stall_memory_throttle |
smsp__warp_issue_stalled_drain_per_warp_active.pct + smsp__warp_issue_stalled_lg_throttle_per_warp_active.pct |
stall_not_selected |
smsp__warp_issue_stalled_not_selected_per_warp_active.pct |
stall_other |
smsp__warp_issue_stalled_dispatch_stall_per_warp_active.pct + smsp__warp_issue_stalled_misc_per_warp_active.pct |
stall_pipe_busy |
smsp__warp_issue_stalled_math_pipe_throttle_per_warp_active.pct + smsp__warp_issue_stalled_mio_throttle_per_warp_active.pct |
stall_sleeping |
smsp__warp_issue_stalled_sleeping_per_warp_active.pct |
stall_sync |
smsp__warp_issue_stalled_barrier_per_warp_active.pct + smsp__warp_issue_stalled_membar_per_warp_active.pct |
stall_texture |
smsp__warp_issue_stalled_tex_throttle_per_warp_active.pct |
surface_atomic_requests |
l1tex__t_requests_pipe_tex_mem_surface_op_atom.sum |
surface_load_requests |
l1tex__t_requests_pipe_tex_mem_surface_op_ld.sum |
surface_reduction_requests |
l1tex__t_requests_pipe_tex_mem_surface_op_red.sum |
surface_store_requests |
l1tex__t_requests_pipe_tex_mem_surface_op_st.sum |
sysmem_read_bytes |
lts__t_sectors_aperture_sysmem_op_read * 32 |
sysmem_read_throughput |
lts__t_sectors_aperture_sysmem_op_read.sum.per_second |
sysmem_read_transactions |
lts__t_sectors_aperture_sysmem_op_read.sum |
sysmem_read_utilization |
n/a |
sysmem_utilization |
n/a |
sysmem_write_bytes |
lts__t_sectors_aperture_sysmem_op_write * 32 |
sysmem_write_throughput |
lts__t_sectors_aperture_sysmem_op_write.sum.per_second |
sysmem_write_transactions |
lts__t_sectors_aperture_sysmem_op_write.sum |
sysmem_write_utilization |
n/a |
tensor_precision_fu_utilization |
sm__pipe_tensor_op_hmma_cycles_active.avg.pct_of_peak_sustained_active |
tensor_precision_int_utilization |
sm__pipe_tensor_op_imma_cycles_active.avg.pct_of_peak_sustained_active (SM 7.2+) |
tex_cache_hit_rate |
l1tex__t_sector_hit_rate.pct |
tex_cache_throughput |
n/a |
tex_cache_transactions |
l1tex__lsu_writeback_active.avg.pct_of_peak_sustained_active + l1tex__tex_writeback_active.avg.pct_of_peak_sustained_active |
tex_fu_utilization |
smsp__inst_executed_pipe_tex.avg.pct_of_peak_sustained_active |
tex_sm_tex_utilization |
l1tex__f_tex2sm_cycles_active.avg.pct_of_peak_sustained_elapsed |
tex_sm_utilization |
sm__mio2rf_writeback_active.avg.pct_of_peak_sustained_elapsed |
tex_utilization |
n/a |
texture_load_requests |
l1tex__t_requests_pipe_tex_mem_texture.sum |
warp_execution_efficiency |
smsp__thread_inst_executed_per_inst_executed.ratio |
warp_nonpred_execution_efficiency |
smsp__thread_inst_executed_per_inst_executed.pct |
4.6.4. Event Comparison
For nvprof events, the following table lists the equivalent metrics in NVIDIA Nsight Compute, if available. For a detailed explanation of the structuring of PerfWorks metrics, see Metrics Structure.
Metrics starting with sm__ are collected per-SM. Metrics starting with smsp__ are collected per-SM subpartition. However, all corresponding nvprof events are collected per-SM, only. Check the Metrics Guide for more details on these terms.
nvprof Event |
PerfWorks Metric or Formula (>= SM 7.0) |
---|---|
active_cycles |
sm__cycles_active.sum |
active_cycles_pm |
sm__cycles_active.sum |
active_cycles_sys |
sys__cycles_active.sum |
active_warps |
sm__warps_active.sum |
active_warps_pm |
sm__warps_active.sum |
atom_count |
smsp__inst_executed_op_generic_atom_dot_alu.sum |
elapsed_cycles_pm |
sm__cycles_elapsed.sum |
elapsed_cycles_sm |
sm__cycles_elapsed.sum |
elapsed_cycles_sys |
sys__cycles_elapsed.sum |
fb_subp0_read_sectors |
dram__sectors_read.sum |
fb_subp1_read_sectors |
dram__sectors_read.sum |
fb_subp0_write_sectors |
dram__sectors_write.sum |
fb_subp1_write_sectors |
dram__sectors_write.sum |
global_atom_cas |
smsp__inst_executed_op_generic_atom_dot_cas.sum |
gred_count |
smsp__inst_executed_op_global_red.sum |
inst_executed |
sm__inst_executed.sum |
inst_executed_fma_pipe_s0 |
smsp__inst_executed_pipe_fma.sum |
inst_executed_fma_pipe_s1 |
smsp__inst_executed_pipe_fma.sum |
inst_executed_fma_pipe_s2 |
smsp__inst_executed_pipe_fma.sum |
inst_executed_fma_pipe_s3 |
smsp__inst_executed_pipe_fma.sum |
inst_executed_fp16_pipe_s0 |
smsp__inst_executed_pipe_fp16.sum |
inst_executed_fp16_pipe_s1 |
smsp__inst_executed_pipe_fp16.sum |
inst_executed_fp16_pipe_s2 |
smsp__inst_executed_pipe_fp16.sum |
inst_executed_fp16_pipe_s3 |
smsp__inst_executed_pipe_fp16.sum |
inst_executed_fp64_pipe_s0 |
smsp__inst_executed_pipe_fp64.sum |
inst_executed_fp64_pipe_s1 |
smsp__inst_executed_pipe_fp64.sum |
inst_executed_fp64_pipe_s2 |
smsp__inst_executed_pipe_fp64.sum |
inst_executed_fp64_pipe_s3 |
smsp__inst_executed_pipe_fp64.sum |
inst_issued1 |
sm__inst_issued.sum |
l2_subp0_read_sector_misses |
lts__t_sectors_op_read_lookup_miss.sum |
l2_subp1_read_sector_misses |
lts__t_sectors_op_read_lookup_miss.sum |
l2_subp0_read_sysmem_sector_queries |
lts__t_sectors_aperture_sysmem_op_read.sum |
l2_subp1_read_sysmem_sector_queries |
lts__t_sectors_aperture_sysmem_op_read.sum |
l2_subp0_read_tex_hit_sectors |
lts__t_sectors_srcunit_tex_op_read_lookup_hit.sum |
l2_subp1_read_tex_hit_sectors |
lts__t_sectors_srcunit_tex_op_read_lookup_hit.sum |
l2_subp0_read_tex_sector_queries |
lts__t_sectors_srcunit_tex_op_read.sum |
l2_subp1_read_tex_sector_queries |
lts__t_sectors_srcunit_tex_op_read.sum |
l2_subp0_total_read_sector_queries |
lts__t_sectors_op_read.sum + lts__t_sectors_op_atom.sum + lts__t_sectors_op_red.sum |
l2_subp1_total_read_sector_queries |
lts__t_sectors_op_read.sum + lts__t_sectors_op_atom.sum + lts__t_sectors_op_red.sum |
l2_subp0_total_write_sector_queries |
lts__t_sectors_op_write.sum + lts__t_sectors_op_atom.sum + lts__t_sectors_op_red.sum |
l2_subp1_total_write_sector_queries |
lts__t_sectors_op_write.sum + lts__t_sectors_op_atom.sum + lts__t_sectors_op_red.sum |
l2_subp0_write_sector_misses |
lts__t_sectors_op_write_lookup_miss.sum |
l2_subp1_write_sector_misses |
lts__t_sectors_op_write_lookup_miss.sum |
l2_subp0_write_sysmem_sector_queries |
lts__t_sectors_aperture_sysmem_op_write.sum |
l2_subp1_write_sysmem_sector_queries |
lts__t_sectors_aperture_sysmem_op_write.sum |
l2_subp0_write_tex_hit_sectors |
lts__t_sectors_srcunit_tex_op_write_lookup_hit.sum |
l2_subp1_write_tex_hit_sectors |
lts__t_sectors_srcunit_tex_op_write_lookup_hit.sum |
l2_subp0_write_tex_sector_queries |
lts__t_sectors_srcunit_tex_op_write.sum |
l2_subp1_write_tex_sector_queries |
lts__t_sectors_srcunit_tex_op_write.sum |
not_predicated_off_thread_inst_executed |
smsp__thread_inst_executed_pred_on.sum |
pcie_rx_active_pulse |
n/a |
pcie_tx_active_pulse |
n/a |
prof_trigger_00 |
n/a |
prof_trigger_01 |
n/a |
prof_trigger_02 |
n/a |
prof_trigger_03 |
n/a |
prof_trigger_04 |
n/a |
prof_trigger_05 |
n/a |
prof_trigger_06 |
n/a |
prof_trigger_07 |
n/a |
inst_issued0 |
smsp__issue_inst0.sum |
sm_cta_launched |
sm__ctas_launched.sum |
shared_load |
smsp__inst_executed_op_shared_ld.sum |
shared_store |
smsp__inst_executed_op_shared_st.sum |
generic_load |
smsp__inst_executed_op_generic_ld.sum |
generic_store |
smsp__inst_executed_op_generic_st.sum |
global_load |
smsp__inst_executed_op_global_ld.sum |
global_store |
smsp__inst_executed_op_global_st.sum |
local_load |
smsp__inst_executed_op_local_ld.sum |
local_store |
smsp__inst_executed_op_local_st.sum |
shared_atom |
smsp__inst_executed_op_shared_atom.sum |
shared_atom_cas |
smsp__inst_executed_op_shared_atom_dot_cas.sum |
shared_ld_bank_conflict |
l1tex__data_bank_conflicts_pipe_lsu_mem_shared_op_ld.sum |
shared_st_bank_conflict |
l1tex__data_bank_conflicts_pipe_lsu_mem_shared_op_st.sum |
shared_ld_transactions |
l1tex__data_pipe_lsu_wavefronts_mem_shared_op_ld.sum |
shared_st_transactions |
l1tex__data_pipe_lsu_wavefronts_mem_shared_op_st.sum |
tensor_pipe_active_cycles_s0 |
smsp__pipe_tensor_cycles_active.sum |
tensor_pipe_active_cycles_s1 |
smsp__pipe_tensor_cycles_active.sum |
tensor_pipe_active_cycles_s2 |
smsp__pipe_tensor_cycles_active.sum |
tensor_pipe_active_cycles_s3 |
smsp__pipe_tensor_cycles_active.sum |
thread_inst_executed |
smsp__thread_inst_executed.sum |
warps_launched |
smsp__warps_launched.sum |
4.6.5. Filtering
Filtering by kernel name
Both nvprof and NVIDIA Nsight Compute CLI support filtering which kernels’ data should be collected. In nvprof, the option is
--kernels
and applies to following metric collection options. In NVIDIA Nsight Compute CLI, the option is named--kernel-name
and applies to the complete application execution. In other words, NVIDIA Nsight Compute CLI does not currently support collecting different metrics for different kernels, unless they execute on different GPU architectures.Filtering by kernel ID
Nvprof allows users to specify which kernels to profile using a kernel ID description, using the same
--kernels
option. In NVIDIA Nsight Compute CLI, the syntax for this kernel ID is identical, but the option is named--kernel-id
.Filtering by device
Both nvprof and NVIDIA Nsight Compute CLI use
--devices
to filter the devices which to profile. In contrast to nvprof, in NVIDIA Nsight Compute CLI the option applies globally, not only to following options.
4.6.6. Output
API trace and summary
NVIDIA Nsight Compute CLI does not support any form of API-usage related output. No API data is captured during profiling.
Dependency analysis
NVIDIA Nsight Compute CLI does not support any dependency analysis. No API data is captured during profiling.
GPU trace
NVIDIA Nsight Compute CLI does not support any GPU trace output. Due to kernel replay during profiling, kernel executions are serialized, and start and end timestamps do not necessarily match those during application execution. In addition, no records for memory activities are recorded.
Print summary
While nvprof has several command line options to specify which summary information to print, NVIDIA Nsight Compute CLI uses further arguments to the
--print-summary
options. Profiling data can be summarizedper-gpu
,per-kernel
orper-nvtx
context.Kernel name demangling
Nvprof allows users to decide between name demangling on or off using the
--demangling
options. NVIDIA Nsight Compute CLI currently always demangles kernel names in the output. In addition, the option--kernel-regex-base
can be used to decide which name format should be used when matching kernel names during filtering.Pages
Nvprof has no concept of output pages, all data is shown as a list or summarized. NVIDIA Nsight Compute CLI uses pages to define how data should be structured and printed. Those correspond to the report pages used in the GUI variant. The option
--page
can be used to select which page to show, anddetails
is selected by default. All pages also support printing in CSV format for easier post-processing, using the--csv
option.
4.6.7. Launch and Attach
Launching a process for profiling
In nvprof, the application to profile is passed to the tool as a command line argument. The application must be a local executable. Alternatively, you can choose to use the tool in a daemon mode and profile all applicable processes on the local machine (nvprof option
--profile-all-processes
). In nvprof, the decision to profile the complete process tree or only the root process is done via the--profile-child-processes
flag. In NVIDIA Nsight Compute CLI, the--target-processes
option is used for this.NVIDIA Nsight Compute CLI has several modes to determine which application to collect data for. By default, the executable passed via the command line to the tool is started, connected to, and profiled. This mode is called
launch-and-attach
.Launching a process for attach
In contrast to nvprof, you can choose to only launch a local executable. In this mode (
--mode launch
), the process is started, connected to, but then suspended at the first CUDA API call. Subsequently, there is a third mode (--mode attach
) to attach to any process launched using the aforementioned mode. In this case, all profiling and output options would be passed to the attaching instance of NVIDIA Nsight Compute CLI.Remote profiling
Finally, using
launch
andattach
, you can connect to a launched process on a remote machine, which could even run a different operating system than the local host. Use--hostname
to select which remote host to connect to.
Notices
Notices
ALL NVIDIA DESIGN SPECIFICATIONS, REFERENCE BOARDS, FILES, DRAWINGS, DIAGNOSTICS, LISTS, AND OTHER DOCUMENTS (TOGETHER AND SEPARATELY, “MATERIALS”) ARE BEING PROVIDED “AS IS.” NVIDIA MAKES NO WARRANTIES, EXPRESSED, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE MATERIALS, AND EXPRESSLY DISCLAIMS ALL IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE.
Information furnished is believed to be accurate and reliable. However, NVIDIA Corporation assumes no responsibility for the consequences of use of such information or for any infringement of patents or other rights of third parties that may result from its use. No license is granted by implication of otherwise under any patent rights of NVIDIA Corporation. Specifications mentioned in this publication are subject to change without notice. This publication supersedes and replaces all other information previously supplied. NVIDIA Corporation products are not authorized as critical components in life support devices or systems without express written approval of NVIDIA Corporation.
Trademarks
NVIDIA and the NVIDIA logo are trademarks or registered trademarks of NVIDIA Corporation in the U.S. and other countries. Other company and product names may be trademarks of the respective companies with which they are associated.