Nsight Compute CLI

The user manual for the NVIDIA Nsight Compute Command Line Interface.

NVIDIA Nsight Compute Command Line Interface (CLI) user manual. Information on workflows, command line options and how to transition from Nvprof.

1. Introduction

NVIDIA Nsight Compute CLI (nv-nsight-cu-cli) 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 nv-nsight-cu-cli instance.

For users migrating from nvprof to NVIDIA Nsight Compute, please additionally see the Nvprof Transition Guide for comparison of features and workflows.

2. Quickstart

  1. 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 nv-nsight-cu-cli. 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 or target/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 in C:\Program Files\NVIDIA Corporation\Nsight Compute <version> on Windows.

    To collect the default set of data for all kernel launches in the target application, launch:
    $ nv-nsight-cu-cli -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 (see Overhead for more details).
    [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" - 1: 0%....50%....100% - 46 passes
    CUDA kernel launch B with 4471 blocks of 256 threads
    ==PROF== Profiling "vectorAdd_B" - 2: 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.nsight-cuprof-report
                
  2. 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 the default section 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 called sections/. See Sets and Sections 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 used on Volta and newer architectures, see Perfworks Metrics API.

    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.

  3. Changing command line output

    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.

    Use --csv to make any output comma separated and easier to process further. See Console Output for further options, e.g. summary views.

  4. Open the report in the UI

    The UI executable is called nv-nsight-cu. 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 or host/linux-desktop-glibc_2_11_3-x64 on Linux. In the UI window, close the Connection 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 nv-nsight-cu <MyReport.nsight-cuprof-report>. Alternatively, when using NVIDIA Nsight Compute CLI on a platform with host support, --open-in-ui can be used directly with nv-nsight-cu-cli 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 paragraph in the user guide for collecting profile information through NVIDIA Nsight Compute.

3. Usage

3.1. Sets and Sections

NVIDIA Nsight Compute CLI uses Section Sets (short sets) to decide, on a very high level, the amount of metrics to be collected . Each set includes one or more Sections, with each section specifying several logically associated metrics. For example, one section might include only high-level SM and memory utilization metrics, while another could include metrics associated with the memory units, or the HW scheduler.

The number and type of metrics specified by a section has significant impact on the overhead during profiling. To allow you to quickly choose between a fast, less detailed profile and a slower, more comprehensive analysis, you can select the respective section set. See Overhead for more information on profiling overhead.

By default, a relatively small number of metrics is collected. Those mostly include high-level utilization information as well as static launch and occupancy data. The latter two are regularly available without replaying the kernel launch. The default set is collected when no --set, --section and no --metrics options are passed on the command line.

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 called sections/. All related command line options can be found here.

3.2. 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. You can choose to connect to a specific process by its process ID or to the first attachable process on the specified system.

3.3. 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. 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, tracking of 32-bit applications is not supported. Profiling of 32-bit processes is not supported on any platform.

3.4. 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: or group: metrics are included.

3.5. Profile Import

Using the --import option, saved reports can be imported into the command line profiler. When using this flag, most other options except File are not available.

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.

3.7. Overhead

As with most measurements, collecting performance data using NVIDIA Nsight Compute CLI incurs some runtime overhead on the application. The overhead does depend on a number of different factors:

  • Number and type of collected metrics

    Depending on the selected metric, data is collected either through a hardware performance monitor on the GPU, through software patching of the kernel instructions or via a launch or device attribute. The overhead between these mechanisms varies greatly, with launch and device attributes being "statically" available and requiring no kernel runtime overhead.

    Furthermore, only a limited number of metrics can be collected in a single pass of the kernel execution. If more metrics are requested, the kernel launch is replayed multiple times, with its accessible memory being saved and restored between subsequent passes to guarantee deterministic execution. Therefore, collecting more metrics can significantly increase overhead by requiring more replay passes and increasing the total amount of memory that needs to be restored during replay.

  • The collected section set

    Since each set specifies a group of section to be collected, choosing a less comprehensive set can reduce profiling overhead. See the --set command in the Profile options.

  • Number of collected sections

    Since each section specifies a set metrics to be collected, selecting fewer sections can reduce profiling overhead. See the --section command in the Profile options.

  • Number of profiled kernels

    By default, all selected metrics are collected for all launched kernels. To reduce the impact on the application, you can try to limit performance data collection to as few kernel functions and instances as makes sense for your analysis. See the filtering commands in the Profile options.

  • GPU Architecture

    NVIDIA Nsight Compute uses different data collection libraries for GPUs of compute capability 7.2 and higher and for those of compute capability 7.0 and below. For 7.2+, there is a relatively high one-time overhead for the first profiled kernel to generate the metric configuration. This overhead does not occur for subsequent kernels in the same context, as long as the list of collected metrics remains unchanged.

3.8. NVTX Filtering

--nvtx-include <configuration> --nvtx-exclude <configuration>

These options are used to profile only those kernels which satisfy the conditions mentioned in the configuration. Through these options, you can choose which kernel falls into a specific range or collection of ranges.

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.





  • Start-End Ranges
    Qauntifier Description Example
    , Delimiter between range names

    Range A,Range B

    Range B,Range A,Range C

    @ Specify domain name. If not mentioned, assuming <default domain>

    Domain A@Range A

    Domain B@Range B,Range Z

    nv-nsight-cu-cli --nvtx --nvtx-include "Domain A@Range A" CuNvtx.exe
                        

    The kernels wrapped inside 'Range A' of 'Domain A' in the application are profiled.

    nv-nsight-cu-cli --nvtx --nvtx-include "Range A,Range B" CuNvtx.exe
                        

    The kernels wrapped inside both ranges, 'Range A' and 'Range B' of '<default domain>' in the application are profiled.

    nv-nsight-cu-cli --nvtx --nvtx-include "Range A" --nvtx-include "Range B" CuNvtx.exe
                        

    The kernels wrapped inside ranges, 'Range A' or 'Range B' of '<default domain>' in the application are profiled.

    nv-nsight-cu-cli --nvtx --nvtx-exclude "Range A" CuNvtx.exe
                        

    All the kernels in the application are profiled except those which are wrapped inside 'Range A' of '<default domain>'.

    nv-nsight-cu-cli --nvtx --nvtx-include "Range B"--nvtx-exclude "Range A" CuNvtx.exe
                        

    The kernels wrapped inside only 'Range B' and not 'Range A' of '<default domain>' in the application are profiled.

  • Push-Pop Ranges
    Qauntifier Description Example
    / Delimiter between range names

    Range A/Range B

    Range A/*/Range B

    Range A/

    [ Range is at the bottom of the stack

    [Range A

    [Range A/+/Range Z

    ] Range is at the top of the stack

    Range Z]

    Range C/*/Range Z]

    + Only one range between the two other ranges

    Range B/+/Range D

    * Zero or more range(s) between the two other ranges

    Range B/*/Range Z

    @ Specify domain name. If not mentioned, assuming <default domain>

    Domain A@Range A

    Domain B@Range A/*/Range Z]

    nv-nsight-cu-cli --nvtx --nvtx-include "Domain A@Range A/" CuNvtx.exe
                        

    The kernels wrapped inside 'Range A' of 'Domain A' in the application are profiled.

    nv-nsight-cu-cli --nvtx --nvtx-include "[Range A" CuNvtx.exe
                        

    The kernels wrapped inside 'Range A' of '<default domain>' where 'Range A' is at the bottom of the stack in the application are profiled.

    nv-nsight-cu-cli --nvtx --nvtx-include "Range A/*/Range B" CuNvtx.exe
                        

    The kernels wrapped inside 'Range A' and 'Range B' of '<default domain>' with zero or many ranges between them in the application are profiled.

    nv-nsight-cu-cli --nvtx --nvtx-exclude "Range A/*/Range B" CuNvtx.exe 
                        

    All the kernels in the application are profiled except those which are wrapped inside 'Range A' and 'Range B' of '<default domain>' with zero or many ranges between them.

    nv-nsight-cu-cli --nvtx --nvtx-include "Range A/" --nvtx-exclude "Range B]" CuNvtx.exe
                        

    The kernels wrapped inside only 'Range A' of '<default domain>' but not inside 'Range B' at the top of the stack in the application are profiled.

  • 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 "Range A\[i\]"
                    

    Quantifiers '@' ',' '[' ']' '/' '*' '+' can be used in range names using prefix '\'. The kernels wrapped inside 'Range A[i]' of '<default domain>' in the application are profiled.

    --nvtx-include "Range A"  //Start/End configuration
    --nvtx-inlcude "Range A/" //Push/Pop configuration
    --nvtx-inlcude "Range A]" //Push/Pop configuration
                    

    Including/Excluding only single range for Push/Pop configuration without specifying stack frame position '[' or ']', use '/' quantifier at the end.

    --nvtx-include "Range A/*/RangeB"
                    

    The order in which you mention Push/Pop configurations is important. In the above example, 'Range A' should be below 'Range B' 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. Command Line Options

4.1. General

Table 1. General Command Line Options
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: Launch the target application and immediately attach for profiling.
  • launch: Launch the target application and suspend in the first intercepted API call, wait for tool to attach.
  • attach: Attach to a previously launched application to which no other tool is attached.
launch-and-attach
p,port Base port used for connecting to target applications 49152
max-connections Maximum number of ports for connecting to target applications 64

4.2. Launch

Table 2. Launch Command Line Options
Option Description Default
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).  
nvtx Enable NVTX support for tools.  
target-processes Select the processes you want to profile. Available modes are:
  • application-only Profile only the root application process.
  • all Profile the application and all its child processes.
This option is only available for Linux and Windows targets.
application-only
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.  

4.3. Attach

Table 3. Attach Command Line Options
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. Profile

Table 4. Profile Command Line Options
Option Description Default
devices List the GPU devices to enable profiling on, separated by comma. All devices
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> : <stream> : <kernel> : <invocation>"" where <context> is the CUDA context ID or regular expression to match the NVTX name <stream> is the CUDA stream ID or regular expression to match the NVTX name <kernel> is the regular expression to match the kernel name <invocation> is the N’th invocation of this kernel function. Multiple invocations can also be specified using regular expressions.  
k,kernel-regex Set the regular expression to use when matching kernel names. If the kernel name does not match the expression, it will be ignored for profiling. If this option is not given, no filtering on kernel names will occur.  
kernel-regex-base Set the basis for --kernel-regex. Options are:
  • function: Function name without parameters, templates etc.
  • demangled: Demangled function name, including parameters, templates, etc.
  • mangled: Mangled function name.
function
c,launch-count Limit the number of collected profile results. The count is only incremented for launches that match the kernel filters.  
s,launch-skip Set the number of kernel launches to skip before starting to profile kernels. 0
launch-skip-before-match Set the number of profile launches to skip before starting to profile. The count is incremented for all launches. 0
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 sets to collect. If not specified, the default set is collected. If no --set options are given, the default set if collected. Use --list-sets to see which set is the default.
list-sections List all sections found in the searched section folders and exit.  
section Add a section identifier to collect. Regular expression allows matching full section identifier. For example, .*Stats, matches all sections ending with 'Stats'. If no --section options are given, the sections associated with the default set are collected. If no sets are found, all sections are collected.
section-folder Add a non-recursive search path for .section files. Section files in this folder will be made available to the --section option. If no --section-folder options are given, the sections folder is added by default.
section-folder-recursive Add a recursive search path for .section files. Section files in this folder and all folders below will be made available to the --section option. If no --section-folder options are given, the sections folder is added by default.
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 --rule to limit which rules to apply. All rules
rule Add a rule identifier to apply. Implies --apply-rules. If no --rule options are given, all applicable rules in the sections folder are applied.
list-metrics List all metrics collected from active sections. If the list of active sections is restricted using the --section option, only metrics from those sections will be listed.  
query-metrics Query available metrics for the devices on system. Use --devices and --chips to filter which devices to query.  
metrics Specify all metrics to be profiled, separated by comma. If no --section options are given, only the temporary section containing all metrics listed using this option is collected. If --section options are given in addition to --metrics, all metrics from those sections and from --metrics are collected.  
chips Specify the chips for querying metrics, separated by comma.  
profile-from-start Set if application should be profiled from its start. Allowed values:
  • on/off
  • yes/no
yes
disable-profiler-start-stop Disable profiler start/stop. When enabled, cu(da)ProfilerStart/Stop API calls are ignored.  
quiet Suppress all profiling output.  
clock-control Control the behavior of the GPU clocks during profiling. Allowed values:
  • base: GPC and memory clocks are locked to their respective base frequency during profiling. This has no impact on thermal throttling.
  • none: No GPC or memory frequencies are changed during profiling.
base
nvtx-include Adds an include statement to the NVTX filter, which allows selecting kernels to profile based on NVTX ranges.  
nvtx-exclude Adds an exclude statement to the NVTX filter, which allows selecting kernels to profile based on NVTX ranges.  

4.5. Sampling

Table 5. Sampling Command Line Options
Option Description Default
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
sampling-max-passes Set maximum number of passes used for sampling (see Overhead for more details). 5
sampling-buffer-size Set the size of the device-sided allocation for samples in bytes. 32*1024*1024

4.6. File

Table 6. File Command Line Options
Option Description Default
o,export Set the output file for writing the profile report. If not set, a temporary file will be used which is removed afterwards. If --export is set and no --page option is given, no profile results will be printed on the console.
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)  

4.7. Console Output

Table 7. Console Output Command Line Options
Option Description Default
csv Use comma-separated values as console output. Implies --units base by default.  
page Select the report page to print console output for. Available pages are:
  • details Show results grouped as sections, include rule results. Some metrics that are collected by default (e.g. device attributes) are omitted if not specified explicitly in any section or using --metrics.
  • raw Show all collected metrics by kernel launch.
details. If no --page option is given and --export is set, no results are printed to the console output.
details-all Include all section metrics on details page.  
units Select the mode for scaling of metric units. Available modes are:
  • auto Show all metrics automatically scaled to the most fitting order of magnitude.
  • base Show all metrics in their base unit.
auto
fp Show all numeric metrics in the console output as floating point numbers. false
summary Select the summary output mode. Available modes are:
  • none No summary.
  • per-gpu Summary for each GPU.
  • per-kernel Summary for each kernel type.
  • per-nvtx Summary for each NVTX context.
none

5. 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.

5.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.

5.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.

  • 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 default 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 default section set if 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.

5.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 for >= SM 7.0, see the PerfWorks Metrics API documentation.

Table 8. Metrics Mapping Table from CUPTI to PerfWorks for Compute Capability 7.0
nvprof Metric PerfWorks Metric or Formula (< SM 7.0) PerfWorks Metric or Formula (>= SM 7.0)
achieved​_occupancy sm​_​_active​_warps​_avg​_per​_active​_cycle​_pct sm​_​_warps​_active.avg.pct​_of​_peak​_sustained​_active
atomic​_transactions n/a l1tex​_​_t​_set​_accesses​_pipe​_lsu​_mem​_global​_op​_atom.sum + l1tex​_​_t​_set​_accesses​_pipe​_lsu​_mem​_global​_op​_red.sum + l1tex​_​_t​_set​_accesses​_pipe​_tex​_mem​_surface​_op​_atom.sum + l1tex​_​_t​_set​_accesses​_pipe​_tex​_mem​_surface​_op​_red.sum
atomic​_transactions​_per​_request n/a n/a
branch​_efficiency n/a n/a
cf​_executed n/a smsp​_​_inst​_executed​_pipe​_cbu.sum + smsp​_​_inst​_executed​_pipe​_adu.sum
cf​_fu​_utilization n/a n/a
cf​_issued n/a n/a
double​_precision​_fu​_utilization n/a smsp​_​_inst​_executed​_pipe​_fp64.avg.pct​_of​_peak​_sustained​_active
dram​_read​_bytes dram​_​_read​_bytes dram​_​_bytes​_read.sum
dram​_read​_throughput dram​_​_read​_bytes​_per​_sec dram​_​_bytes​_read.sum.per​_second
dram​_read​_transactions dram​_​_read​_sectors dram​_​_sectors​_read.sum
dram​_utilization n/a dram​_​_throughput.avg.pct​_of​_peak​_sustained​_elapsed
dram​_write​_bytes dram​_​_write​_bytes dram​_​_bytes​_write.sum
dram​_write​_throughput dram​_​_write​_bytes​_per​_sec dram​_​_bytes​_write.sum.per​_second
dram​_write​_transactions dram​_​_write​_sectors dram​_​_sectors​_write.sum
eligible​_warps​_per​_cycle n/a smsp​_​_warps​_eligible.sum.per​_cycle​_active
flop​_count​_dp n/a 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
flop​_count​_dp​_add n/a smsp​_​_sass​_thread​_inst​_executed​_op​_dadd​_pred​_on.sum
flop​_count​_dp​_fma n/a smsp​_​_sass​_thread​_inst​_executed​_op​_dfma​_pred​_on.sum
flop​_count​_dp​_mul n/a smsp​_​_sass​_thread​_inst​_executed​_op​_dmul​_pred​_on.sum
flop​_count​_hp n/a 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
flop​_count​_hp​_add n/a smsp​_​_sass​_thread​_inst​_executed​_op​_hadd​_pred​_on.sum
flop​_count​_hp​_fma n/a smsp​_​_sass​_thread​_inst​_executed​_op​_hfma​_pred​_on.sum
flop​_count​_hp​_mul n/a smsp​_​_sass​_thread​_inst​_executed​_op​_hmul​_pred​_on.sum
flop​_count​_sp n/a 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
flop​_count​_sp​_add n/a smsp​_​_sass​_thread​_inst​_executed​_op​_fadd​_pred​_on.sum
flop​_count​_sp​_fma n/a smsp​_​_sass​_thread​_inst​_executed​_op​_ffma​_pred​_on.sum
flop​_count​_sp​_mul n/a smsp​_​_sass​_thread​_inst​_executed​_op​_fmul​_pred​_on.sum
flop​_count​_sp​_special n/a smsp​_​_sass​_thread​_inst​_executed​_op​_mufu​_pred​_on.sum
flop​_dp​_efficiency n/a n/a
flop​_hp​_efficiency n/a n/a
flop​_sp​_efficiency n/a n/a
gld​_efficiency n/a n/a
gld​_requested​_throughput n/a n/a
gld​_throughput n/a l1tex​_​_t​_bytes​_pipe​_lsu​_mem​_global​_op​_ld.sum.per​_second
gld​_transactions n/a l1tex​_​_t​_sectors​_pipe​_lsu​_mem​_global​_op​_ld.sum
gld​_transactions​_per​_request n/a n/a
global​_atomic​_requests tex​_​_texin​_requests​_global​_atom l1tex​_​_t​_requests​_pipe​_lsu​_mem​_global​_op​_atom.sum
global​_hit​_rate n/a l1tex​_​_t​_sectors​_pipe​_lsu​_mem​_global​_op​_{op}​_lookup​_hit.sum / l1tex​_​_t​_sectors​_pipe​_lsu​_mem​_global​_op​_{op}.sum
global​_load​_requests n/a l1tex​_​_t​_requests​_pipe​_lsu​_mem​_global​_op​_ld.sum
global​_reduction​_requests tex​_​_texin​_requests​_global​_red l1tex​_​_t​_requests​_pipe​_lsu​_mem​_global​_op​_red.sum
global​_store​_requests tex​_​_texin​_requests​_global​_st l1tex​_​_t​_requests​_pipe​_lsu​_mem​_global​_op​_st.sum
gst​_efficiency n/a n/a
gst​_requested​_throughput n/a n/a
gst​_throughput n/a l1tex​_​_t​_bytes​_pipe​_lsu​_mem​_global​_op​_st.sum.per​_second
gst​_transactions n/a l1tex​_​_t​_bytes​_pipe​_lsu​_mem​_global​_op​_st.sum
gst​_transactions​_per​_request n/a n/a
half​_precision​_fu​_utilization n/a smsp​_​_inst​_executed​_pipe​_fp16.sum
inst​_bit​_convert n/a smsp​_​_sass​_thread​_inst​_executed​_op​_conversion​_pred​_on.sum
inst​_compute​_ld​_st n/a smsp​_​_sass​_thread​_inst​_executed​_op​_memory​_pred​_on.sum
inst​_control n/a smsp​_​_sass​_thread​_inst​_executed​_op​_control​_pred​_on.sum
inst​_executed smsp​_​_inst​_executed​_sum smsp​_​_inst​_executed.sum
inst​_executed​_global​_atomics smsp​_​_inst​_executed​_global​_atomics​_sum smsp​_​_inst​_executed​_op​_global​_atom.sum
inst​_executed​_global​_loads smsp​_​_inst​_executed​_global​_loads​_sum smsp​_​_inst​_executed​_op​_global​_ld.sum
inst​_executed​_global​_reductions smsp​_​_inst​_executed​_global​_reductions​_sum smsp​_​_inst​_executed​_op​_global​_red.sum
inst​_executed​_global​_stores smsp​_​_inst​_executed​_generic​_stores​_sum smsp​_​_inst​_executed​_op​_global​_st.sum
inst​_executed​_local​_loads smsp​_​_inst​_executed​_local​_loads​_sum smsp​_​_inst​_executed​_op​_local​_ld.sum
inst​_executed​_local​_stores smsp​_​_inst​_executed​_local​_stores​_sum smsp​_​_inst​_executed​_op​_local​_st.sum
inst​_executed​_shared​_atomics smsp​_​_inst​_executed​_shared​_atomics​_sum 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​_shared​_loads​_sum smsp​_​_inst​_executed​_op​_shared​_ld.sum
inst​_executed​_shared​_stores smsp​_​_inst​_executed​_shared​_stores​_sum smsp​_​_inst​_executed​_op​_shared​_st.sum
inst​_executed​_surface​_atomics smsp​_​_inst​_executed​_surface​_atomics​_sum smsp​_​_inst​_executed​_op​_surface​_atom.sum
inst​_executed​_surface​_loads smsp​_​_inst​_executed​_surface​_loads​_sum 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​_surface​_reductions​_sum smsp​_​_inst​_executed​_op​_surface​_red.sum
inst​_executed​_surface​_stores smsp​_​_inst​_executed​_surface​_stores​_sum smsp​_​_inst​_executed​_op​_surface​_st.sum
inst​_executed​_tex​_ops n/a smsp​_​_inst​_executed​_op​_texture.sum
inst​_fp​_16 n/a smsp​_​_sass​_thread​_inst​_executed​_op​_fp16​_pred​_on.sum
inst​_fp​_32 n/a smsp​_​_sass​_thread​_inst​_executed​_op​_fp32​_pred​_on.sum
inst​_fp​_64 n/a smsp​_​_sass​_thread​_inst​_executed​_op​_fp64​_pred​_on.sum
inst​_integer n/a smsp​_​_sass​_thread​_inst​_executed​_op​_integer​_pred​_on.sum
inst​_inter​_thread​_communication n/a smsp​_​_sass​_thread​_inst​_executed​_op​_inter​_thread​_communication​_pred​_on.sum
inst​_issued smsp​_​_inst​_issued​_sum smsp​_​_inst​_issued.sum
inst​_misc n/a smsp​_​_sass​_thread​_inst​_executed​_op​_misc​_pred​_on.sum
inst​_per​_warp n/a smsp​_​_average​_inst​_executed​_per​_warp.ratio
inst​_replay​_overhead n/a n/a
ipc smsp​_​_inst​_executed​_avg​_per​_active​_cycle smsp​_​_inst​_executed.avg.per​_cycle​_active
issue​_slot​_utilization n/a smsp​_​_issue​_active.avg.pct​_of​_peak​_sustained​_active
issue​_slots smsp​_​_inst​_issued​_sum smsp​_​_inst​_issued.sum
issued​_ipc smsp​_​_inst​_issued​_avg​_per​_active​_cycle smsp​_​_inst​_issued.avg.per​_cycle​_active
l1​_sm​_lg​_utilization n/a l1tex​_​_lsu​_writeback​_active.sum
l2​_atomic​_throughput n/a lts​_​_t​_sectors​_srcunit​_l1​_op​_atom.sum.per​_second
l2​_atomic​_transactions n/a lts​_​_t​_sectors​_srcunit​_l1​_op​_atom.sum
l2​_global​_atomic​_store​_bytes n/a lts​_​_t​_bytes​_equiv​_l1sectormiss​_pipe​_lsu​_mem​_global​_op​_atom.sum
l2​_global​_load​_bytes n/a lts​_​_t​_bytes​_equiv​_l1sectormiss​_pipe​_lsu​_mem​_global​_op​_ld.sum
l2​_local​_global​_store​_bytes n/a lts​_​_t​_bytes​_equiv​_l1sectormiss​_pipe​_lsu​_mem​_global​_op​_st.sum
l2​_local​_load​_bytes n/a lts​_​_t​_bytes​_equiv​_l1sectormiss​_pipe​_lsu​_mem​_global​_op​_ld.sum
l2​_read​_throughput n/a lts​_​_t​_sectors​_op​_read.sum.per​_second
l2​_read​_transactions n/a lts​_​_t​_sectors​_op​_read.sum
l2​_surface​_load​_bytes n/a lts​_​_t​_bytes​_equiv​_l1sectormiss​_pipe​_tex​_mem​_surface​_op​_ld.sum
l2​_surface​_store​_bytes n/a lts​_​_t​_bytes​_equiv​_l1sectormiss​_pipe​_lsu​_mem​_surface​_op​_st.sum
l2​_tex​_hit​_rate n/a lts​_​_t​_sector​_hit​_rate.pct
l2​_tex​_read​_hit​_rate n/a lts​_​_t​_sector​_op​_read​_hit​_rate.pct
l2​_tex​_read​_throughput n/a lts​_​_t​_sectors​_srcunit​_tex​_op​_read.sum.per​_second
l2​_tex​_read​_transactions n/a lts​_​_t​_sectors​_srcunit​_tex​_op​_read.sum
l2​_tex​_write​_hit​_rate n/a lts​_​_t​_sector​_op​_write​_hit​_rate.pct
l2​_tex​_write​_throughput n/a lts​_​_t​_sectors​_srcunit​_tex​_op​_read.sum.per​_second
l2​_tex​_write​_transactions n/a lts​_​_t​_sectors​_srcunit​_tex​_op​_read.sum
l2​_utilization n/a lts​_​_t​_sectors.avg.pct​_of​_peak​_sustained​_elapsed
l2​_write​_throughput n/a lts​_​_t​_sectors​_op​_write.sum.per​_second
l2​_write​_transactions n/a lts​_​_t​_sectors​_op​_write.sum
ldst​_executed n/a n/a
ldst​_fu​_utilization n/a smsp​_​_inst​_executed​_pipe​_lsu.avg.pct​_of​_peak​_sustained​_active
ldst​_issued n/a n/a
local​_hit​_rate n/a n/a
local​_load​_requests n/a l1tex​_​_t​_requests​_pipe​_lsu​_mem​_local​_op​_ld.sum
local​_load​_throughput n/a l1tex​_​_t​_bytes​_pipe​_lsu​_mem​_local​_op​_ld.sum.per​_second
local​_load​_transactions n/a l1tex​_​_t​_sectors​_pipe​_lsu​_mem​_local​_op​_ld.sum
local​_load​_transactions​_per​_request n/a n/a
local​_memory​_overhead n/a n/a
local​_store​_requests n/a l1tex​_​_t​_requests​_pipe​_lsu​_mem​_local​_op​_st.sum
local​_store​_throughput n/a l1tex​_​_t​_sectors​_pipe​_lsu​_mem​_local​_op​_st.sum.per​_second
local​_store​_transactions n/a l1tex​_​_t​_sectors​_pipe​_lsu​_mem​_local​_op​_st.sum
local​_store​_transactions​_per​_request n/a n/a
nvlink​_data​_receive​_efficiency n/a n/a
nvlink​_data​_transmission​_efficiency n/a n/a
nvlink​_overhead​_data​_received n/a n/a
nvlink​_overhead​_data​_transmitted n/a n/a
nvlink​_receive​_throughput n/a n/a
nvlink​_total​_data​_received n/a n/a
nvlink​_total​_data​_transmitted n/a n/a
nvlink​_total​_nratom​_data​_transmitted n/a n/a
nvlink​_total​_ratom​_data​_transmitted n/a n/a
nvlink​_total​_response​_data​_received n/a n/a
nvlink​_total​_write​_data​_transmitted n/a n/a
nvlink​_transmit​_throughput n/a n/a
nvlink​_user​_data​_received n/a n/a
nvlink​_user​_data​_transmitted n/a n/a
nvlink​_user​_nratom​_data​_transmitted n/a n/a
nvlink​_user​_ratom​_data​_transmitted n/a n/a
nvlink​_user​_response​_data​_received n/a n/a
nvlink​_user​_write​_data​_transmitted n/a n/a
pcie​_total​_data​_received n/a n/a
pcie​_total​_data​_transmitted n/a n/a
shared​_efficiency n/a n/a
shared​_load​_throughput n/a smsp​_​_inst​_executed​_op​_shared​_ld.sum.per​_second
shared​_load​_transactions n/a smsp​_​_inst​_executed​_op​_shared​_ld.sum
shared​_load​_transactions​_per​_request n/a n/a
shared​_store​_throughput n/a smsp​_​_inst​_executed​_op​_shared​_st.sum.per​_second
shared​_store​_transactions n/a smsp​_​_inst​_executed​_op​_shared​_st.sum
shared​_store​_transactions​_per​_request n/a n/a
shared​_utilization n/a smsp​_​_inst​_executed​_op​_shared​_ld.avg.pct​_of​_peak​_sustained​_elapsed + smsp​_​_inst​_executed​_op​_shared​_st.avg.pct​_of​_peak​_sustained​_elapsed
single​_precision​_fu​_utilization n/a smsp​_​_pipe​_fma​_cycles​_active.avg.pct​_of​_peak​_sustained​_active
sm​_efficiency n/a smsp​_​_cycles​_active.avg.pct​_of​_peak​_sustained​_elapsed
sm​_tex​_utilization n/a l1tex​_​_texin​_sm2tex​_req​_cycles​_active.avg.pct​_of​_peak​_sustained​_elapsed
special​_fu​_utilization n/a smsp​_​_inst​_executed​_pipe​_xu.avg.pct​_of​_peak​_sustained​_active
stall​_constant​_memory​_dependency n/a smsp​_​_warp​_issue​_stalled​_imc​_miss​_per​_warp​_active.pct
stall​_exec​_dependency n/a smsp​_​_warp​_issue​_stalled​_short​_scoreboard​_miss​_per​_warp​_active.pct
stall​_inst​_fetch n/a smsp​_​_warp​_issue​_stalled​_no​_instruction​_miss​_per​_warp​_active.pct
stall​_memory​_dependency n/a smsp​_​_warp​_issue​_stalled​_long​_scoreboard​_miss​_per​_warp​_active.pct
stall​_memory​_throttle n/a smsp​_​_warp​_issue​_stalled​_drain​_miss​_per​_warp​_active.pct
stall​_not​_selected n/a smsp​_​_warp​_issue​_stalled​_not​_selected​_miss​_per​_warp​_active.pct
stall​_other n/a smsp​_​_warp​_issue​_stalled​_misc​_miss​_per​_warp​_active.pct
stall​_pipe​_busy n/a smsp​_​_warp​_issue​_stalled​_misc​_mio​_throttle​_per​_warp​_active.pct
stall​_sleeping n/a smsp​_​_warp​_issue​_stalled​_misc​_sleeping​_per​_warp​_active.pct
stall​_sync n/a smsp​_​_warp​_issue​_stalled​_misc​_membar​_per​_warp​_active.pct
stall​_texture n/a smsp​_​_warp​_issue​_stalled​_misc​_tex​_throttle​_per​_warp​_active.pct
surface​_atomic​_requests n/a l1tex​_​_t​_requests​_pipe​_tex​_mem​_surface​_op​_atom.sum
surface​_load​_requests n/a l1tex​_​_t​_requests​_pipe​_tex​_mem​_surface​_op​_ld.sum
surface​_reduction​_requests n/a l1tex​_​_t​_requests​_pipe​_tex​_mem​_surface​_op​_red.sum
surface​_store​_requests n/a l1tex​_​_t​_requests​_pipe​_tex​_mem​_surface​_op​_st.sum
sysmem​_read​_bytes n/a n/a
sysmem​_read​_throughput n/a lts​_​_t​_sectors​_aperture​_sysmem​_op​_read.sum.per​_second
sysmem​_read​_transactions n/a lts​_​_t​_sectors​_aperture​_sysmem​_op​_read.sum
sysmem​_read​_utilization n/a n/a
sysmem​_utilization n/a n/a
sysmem​_write​_bytes n/a n/a
sysmem​_write​_throughput n/a lts​_​_t​_sectors​_aperture​_sysmem​_op​_write.sum.per​_second
sysmem​_write​_transactions n/a lts​_​_t​_sectors​_aperture​_sysmem​_op​_write.sum
sysmem​_write​_utilization n/a n/a
tensor​_precision​_fu​_utilization n/a sm​_​_pipe​_tensor​_cycles​_active.avg.pct​_of​_peak​_sustained​_active
tex​_cache​_hit​_rate n/a l1tex​_​_t​_sector​_hit​_rate.pct
tex​_cache​_throughput n/a n/a
tex​_cache​_transactions n/a l1tex​_​_lsu​_writeback​_active.avg.pct​_of​_peak​_sustained​_active + l1tex​_​_tex​_writeback​_active.avg.pct​_of​_peak​_sustained​_active
tex​_fu​_utilization n/a smsp​_​_inst​_executed​_pipe​_tex.avg.pct​_of​_peak​_sustained​_active
tex​_sm​_tex​_utilization n/a l1tex​_​_f​_tex2sm​_cycles​_active.avg.pct​_of​_peak​_sustained​_elapsed
tex​_sm​_utilization n/a sm​_​_mio2rf​_writeback​_active.avg.pct​_of​_peak​_sustained​_elapsed
tex​_utilization n/a n/a
texture​_load​_requests n/a l1tex​_​_t​_requests​_pipe​_tex​_mem​_texture.sum
warp​_execution​_efficiency smsp​_​_thread​_inst​_executed​_per​_inst​_executed​_pct smsp​_​_thread​_inst​_executed​_per​_inst​_executed.ratio
warp​_nonpred​_execution​_efficiency smsp​_​_thread​_inst​_executed​_not​_pred​_off​_per​_inst​_executed​_pct smsp​_​_thread​_inst​_executed​_per​_inst​_executed.pct

5.4. 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-regex 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.

5.5. 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 --summary options. Profiling data can be summarized per-gpu, per-kernel or per-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, and details is selected by default. All pages also support printing in CSV format for easier post-processing, using the --csv option.

5.6. 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.

    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 and attach, 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

Notice

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.