CUDA 调试器入门 :: NVIDIA Nsight VSCE 文档

1. 演练：启动和调试 CUDA 应用程序

在以下演练中，我们将介绍您可能用于调试基于 CUDA 的应用程序的一些更常见的过程。我们使用名为 Matrix Multiply 的示例应用程序作为示例。CUDA 工具包 CUDA 示例和 GitHub 上的 NVIDIA/cuda-samples 存储库包含此示例应用程序。

1.1. 打开示例项目并设置断点

在 Visual Studio Code 中，打开 CUDA 示例中名为 matrixMul 的目录。

有关查找示例应用程序的帮助，请参阅使用示例。

注意：

此文件包含 CPU 代码（即 matrixMultiply()）和 GPU 代码（即 matrixMultiplyCUDA()，任何使用 __global__ 或 __device__ 关键字指定的函数）。

首先，让我们在 GPU 代码中设置一些断点。
1. 打开名为 matrixMul.cu 的文件，并找到 CUDA 内核函数 matrixMulCUDA()。
2. 在以下位置设置断点
```
int aStep  =  BLOCK_SIZE
```
3. 在以以下语句开头的行设置另一个断点
```
for {int a = aBegin, b = bBegin;
```
现在，让我们在 CPU 代码中设置一些断点
1. 在同一文件 matrixMul.cu 中，找到 CPU 函数 matrixMultiply()。
2. 在以下位置设置一个断点
```
if (block_size == 16)
```
3. 在以以下语句开头的行设置另一个断点：
```
printf("done\n"); 
```

1.2. 创建启动配置

为了调试我们的应用程序，我们必须首先创建一个启动配置。要创建 launch.json，首先转到 运行和调试 选项卡，然后单击 创建 launch.json 文件。

为环境选择 CUDA C++ (CUDA-GDB)。

以下是为 CUDA 调试生成的启动配置

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "CUDA C++: Launch",
            "type": "cuda-gdb",
            "request": "launch",
            "program": ""
        }
    ]
}

在 launch.json 中，将 program 属性更改为 ${workspaceFolder}/matrixMul。

注意：

${workspaceFolder} 是一个预定义变量，表示在 VS Code 中打开的文件夹的路径。

启动配置的其他可用属性包括

debuggerPath：cuda-gdb 的路径。如果未指定，将搜索 cuda-gdb 的路径。
args：传递给被调试程序debuggee的命令行参数。可以是字符串或数组。示例：“arg1”或 [“arg1”, “arg2”]。双重转义转义字符。示例：["{\\\"arg1\\\": true}"] 将向应用程序发送 {"arg1": true}。
initCommands：在启动 inferior 之前发送的 GDB 命令列表。
breakOnLaunch：在每个启动的内核的第一条指令处中断。
logfile：指示在发生驱动程序 API 或运行时 API 错误时要执行的操作。有效值为 hide、ignore 和 stop。
logFile：可以设置为 ${workspaceFolder}/myLogFile.txt，例如，启用 cuda-gdb 中的日志记录，以帮助客户支持找到遇到的任何问题的根本原因。可以使用 Nsight VSCE 开发者论坛上传日志文件。
miDebuggerArgs：在启动调试器（例如 cuda-gdb）时传递自定义命令行参数。示例：“miDebuggerArgs”: [“--quiet”]
miDebuggerPath：指定调试器（例如 cuda-gdb）的路径。示例：“miDebuggerPath”: “/usr/local/bin/cuda-gdb”。如果未指定，它将在操作系统的 PATH 变量中搜索 cuda-gdb。

1.3. 构建示例并启动调试器

为了构建我们的应用程序，我们必须首先将我们的构建系统与任务集成。转到命令面板并执行 任务：配置默认构建任务 命令。

以下是生成的任务配置

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "echo",
            "type": "shell",
            "command": "echo Hello",
            "problemMatcher": [],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

进行以下更改以配置任务以构建用于调试的 matrixMul 项目

将 command 属性更改为 make dbg=1。需要 dbg 变量才能生成带有符号信息的未优化代码。
将 "$nvcc" 添加到 problemMatcher 数组。这将检测 nvcc 构建错误并将它们传播到 Visual Studio Code 问题面板。

要构建任务，请再次转到命令面板并运行 任务：运行构建任务 任务。查看问题和终端面板以查找错误消息。

要开始调试，请转到 运行和调试 选项卡，然后单击 开始调试 按钮，或者直接按 F5。

您已启动调试会话。在控制 GPU 执行和检查状态主题中，我们将介绍您在调试会话期间通常使用的一些工具。

2. 演练：使用附加调试正在运行的 CUDA 应用程序

在本演练中，我们将附加并调试正在运行的基于 CUDA 的应用程序。与上次演练一样，我们将使用 Matrix Multiply 作为我们的应用程序。CUDA 工具包 CUDA 示例和 GitHub 上的 NVIDIA/cuda-samples 存储库包含此示例应用程序。

2.1. 打开示例项目，进行小幅编辑，并设置断点

在 Visual Studio Code 中，打开 CUDA 示例中名为 matrixMul 的目录。

有关查找示例应用程序的帮助，请参阅使用示例。

注意：

此文件包含 CPU 代码（即 matrixMultiply()）和 GPU 代码（即 matrixMultiplyCUDA()，任何使用 __global__ 或 __device__ 关键字指定的函数）。

在 main() 入口点的第一个 printf 之后添加 sleep(100);。这将有效地暂停程序，以便我们可以附加到正在运行的进程。
然后我们设置一些断点，就像在启动演练中一样。首先，在 GPU 代码中。
1. 打开名为 matrixMul.cu 的文件，并找到 CUDA 内核函数 matrixMulCUDA()。
2. 在以下位置设置断点
```
int aStep  =  BLOCK_SIZE
```
3. 在以以下语句开头的行设置另一个断点
```
for {int a = aBegin, b = bBegin;
```
然后是在 CPU 代码中设置一些断点
1. 在同一文件 matrixMul.cu 中，找到 CPU 函数 matrixMultiply()。
2. 在以下位置设置一个断点
```
if (block_size == 16)
```
3. 在以以下语句开头的行设置另一个断点：
```
printf("done\n"); 
```

2.2. 创建启动配置以附加到正在运行的进程

为了调试我们的应用程序，我们必须首先创建一个启动配置。要创建 launch.json，首先转到 运行和调试 选项卡，然后单击 创建 launch.json 文件。

为环境选择 CUDA C++ (CUDA-GDB)。

以下是为 CUDA 调试生成的启动配置

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "CUDA C++: Attach",
            "type": "cuda-gdb",
            "request": "attach",
            "processId": "${command:cuda.pickProcess}"
        }
    ]
}

注意：

${command:cuda.pickProcess} 是一个预定义变量，表示打开 processPicker 以选择要在 VS Code 中选择的进程的函数。

启动配置的其他可用属性包括

debuggerPath：cuda-gdb 的路径。如果未指定，将搜索 cuda-gdb 的路径。
args：传递给被调试程序debuggee的命令行参数。可以是字符串或数组。示例：“arg1”或 [“arg1”, “arg2”]。双重转义转义字符。示例：["{\\\"arg1\\\": true}"] 将向应用程序发送 {"arg1": true}。
initCommands：在启动 inferior 之前发送的 GDB 命令列表。
breakOnLaunch：在每个启动的内核的第一条指令处中断。
onAPIError：指示在发生驱动程序 API 或运行时 API 错误时要执行的操作。有效值为 hide、ignore 和 stop。
logFile：可以设置为 ${workspaceFolder}/myLogFile.txt，例如，启用 cuda-gdb 中的日志记录，以帮助客户支持找到遇到的任何问题的根本原因。可以使用 Nsight VSCE 开发者论坛上传日志文件。
miDebuggerArgs：在启动调试器（例如 cuda-gdb）时传递自定义命令行参数。示例：“miDebuggerArgs”: [“--quiet”]
miDebuggerPath：指定调试器（例如 cuda-gdb）的路径。示例：“miDebuggerPath”: “/usr/local/bin/cuda-gdb”。如果未指定，它将在操作系统的 PATH 变量中搜索 cuda-gdb。

2.3. 构建示例

为了构建我们的应用程序，我们必须首先将我们的构建系统与任务集成。转到命令面板并执行 任务：配置默认构建任务 命令。

以下是生成的任务配置

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "echo",
            "type": "shell",
            "command": "echo Hello",
            "problemMatcher": [],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

进行以下更改以配置任务以构建用于调试的 matrixMul 项目

将 command 属性更改为 make dbg=1。需要 dbg 变量才能生成带有符号信息的未优化代码。
将 "$nvcc" 添加到 problemMatcher 数组。这将检测 nvcc 构建错误并将它们传播到 Visual Studio Code 问题面板。

要构建任务，请再次转到命令面板并运行 任务：运行构建任务 任务。查看问题和终端面板以查找错误消息。

2.4. 启动应用程序

通过在 matrixMul 文件夹中的终端上运行 ./matrixMul & 在后台启动 matrixMul。

2.5. 启动调试器并附加到正在运行的应用程序

在 sleep(100) 过期之前，启动调试器以附加到程序。

要开始调试，请转到 运行和调试 选项卡，然后单击 开始调试 按钮，或者直接按 F5。

将出现一个进程选择器。选择 matrixMul 以开始您的调试会话。

一旦 sleep(100) 过期，您的代码执行将停止在 sleep(100) 之后执行的第一条指令处，您在该指令处设置了断点。您可以单步执行，按 F5 继续，或按 SHIFT-F5 分离并允许应用程序自由运行。

应用程序终止后，删除您命中的第一个断点并重复该过程以找到您可以命中的其他断点。

在控制 GPU 执行和检查状态主题中，我们将介绍您在调试会话期间通常使用的一些工具。

3. 演练：使用 cuda-gdbserver 启动和调试远程应用程序

在以下演练中，我们将介绍您可能用于调试远程目标机器上基于 CUDA 的应用程序的一些更常见的过程。我们使用名为 Matrix Multiply 的示例应用程序作为示例。CUDA 工具包 CUDA 示例和 GitHub 上的 NVIDIA/cuda-samples 存储库包含此示例应用程序。

3.1. 打开示例项目并设置断点

在本地计算机上，

在 Visual Studio Code 中，打开 CUDA 示例中名为 matrixMul 的目录。

有关查找示例应用程序的帮助，请参阅使用示例。

注意：

此文件包含 CPU 代码（即 matrixMultiply()）和 GPU 代码（即 matrixMultiplyCUDA()，任何使用 __global__ 或 __device__ 关键字指定的函数）。

首先，让我们在 GPU 代码中设置一些断点。
1. 打开名为 matrixMul.cu 的文件，并找到 CUDA 内核函数 matrixMulCUDA()。
2. 在以下位置设置断点
```
int aStep  =  BLOCK_SIZE
```
3. 在以以下语句开头的行设置另一个断点
```
for {int a = aBegin, b = bBegin;
```
现在，让我们在 CPU 代码中设置一些断点
1. 在同一文件 matrixMul.cu 中，找到 CPU 函数 matrixMultiply()。
2. 在以下位置设置一个断点
```
if (block_size == 16)
```
3. 在以以下语句开头的行设置另一个断点：
```
printf("done\n"); 
```

3.2. 创建启动配置

为了调试我们的应用程序，我们必须首先创建一个启动配置。要创建 launch.json，首先转到 运行和调试 选项卡，然后单击 创建 launch.json 文件。

为环境选择 CUDA C++ (CUDA-GDBSERVER)。

以下是为 CUDA 调试生成的启动配置

{
	"version": "0.2.0",
	"configurations": [
		{
			"name": "CUDA C++: Launch",
			"type": "cuda-gdbserver",
			"request": "launch",
			"server": "cuda-gdbserver",
			"program": "",
			"target": {
				"host": "${config:host}",
				"port": "${config:port}"
			},
			"additionalSOLibSearchPath": "",
		}
	]
}

在 launch.json 中，

将 program 属性更改为 ${workspaceFolder}/matrixMul，
将目标属性（主机和端口）设置为您将运行的 cuda-gdbserver 的主机和端口，并且
将 additionalSOLibSearchPath 设置为调试器搜索共享库的目录。

注意：

${workspaceFolder} 是一个预定义变量，表示在 VS Code 中打开的文件夹的路径。

启动配置的其他可用属性包括

additionalSOLibSearchPath：调试器搜索共享库的目录。
args：传递给被调试程序debuggee的命令行参数。可以是字符串或数组。示例：“arg1”或 [“arg1”, “arg2”]。双重转义转义字符。示例：["{\\\"arg1\\\": true}"] 将向应用程序发送 {"arg1": true}。
breakOnLaunch：在每个启动的内核的第一条指令处中断。
cwd：被调试程序进程的当前工作目录 (cwd)。
debuggerPath：cuda-gdb 的路径。如果未指定，将搜索 cuda-gdb 的路径。
environment：包含指定环境变量的对象的数组。
envFile：包含 VAR=VALUE 行以指定环境变量的文件的绝对路径。
initCommands：在启动 inferior 之前发送的 GDB 命令列表。
logFile：用于记录与 cuda-gdb 交互的文件的绝对路径。可以设置为 ${workspaceFolder}/myLogFile.txt，例如，启用 cuda-gdb 中的日志记录，以帮助客户支持找到遇到的任何问题的根本原因。可以使用 Nsight VSCE 开发者论坛上传日志文件。
miDebuggerArgs：在启动调试器（例如 cuda-gdb）时传递自定义命令行参数。示例：“miDebuggerArgs”: [“--quiet”]
miDebuggerPath：指定调试器（例如 cuda-gdb）的路径。示例：“miDebuggerPath”: “/usr/local/bin/cuda-gdb”。如果未指定，它将在操作系统的 PATH 变量中搜索 cuda-gdb。
onAPIError：指示在发生驱动程序 API 或运行时 API 错误时要执行的操作。有效值为 hide、ignore 和 stop。
program：要调试的程序的路径。
stopAtEntry：在被调试程序的第一条指令处中断。
sysroot：包含目标库副本的本地目录。
目标:
- Host：要连接的目标主机。
- Port：要连接的目标端口。
- Connect commands：要运行的命令。
verboseLogging：设置为 true 以生成详细的日志输出。

3.3. 构建示例

为了构建我们的应用程序，我们必须首先将我们的构建系统与任务集成。转到命令面板并执行 任务：配置默认构建任务 命令。

以下是生成的任务配置

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "echo",
            "type": "shell",
            "command": "echo Hello",
            "problemMatcher": [],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

3.4. 将示例复制到远程机器并在远程机器上实例化 cuda-gdbserver

在构建示例之后，我们使用预定义的自动启动任务将示例复制到远程机器并在远程机器上实例化 cuda-gdbserver。转到命令面板并执行 任务：配置默认构建任务 命令。

将列出多个任务选项，对于这种情况，您需要选择 Nsight：自动启动（安全复制可执行二进制文件，远程）。

以下是生成的任务配置

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Nsight: autostart (secure copy executable binary, remote)",
            "type": "shell",
            "command": "scp ${config:executable} ${config:username}@${config:host}:/tmp && ssh ${config:username}@${config:host} \"cuda-gdbserver ${config:host}:${config:port} /tmp/${config:execName}\"",
            "problemMatcher": [],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

此时，您可以替换 tasks.json 中 executable、username、host、port 的值，或者通过创建 settings.json 为它们提供值。建议您创建 settings.json，因为这样您也可以在 launch.json 中访问这些值。

如果您创建 settings.json，它将如下所示

{
    "version": "2.0.0",
    "tasks": [
        {
            "username": "uname",
            "host": "127.0.0.1",
            "port": "12345",
            "executable": "${workspaceFolder}/matrixMul",
            "execName": "matrixMul"
        }
    ]
}

要运行任务，请再次转到命令面板并运行 任务：运行构建任务 任务。查看问题和终端面板以查找错误消息。

要开始调试，请执行以下操作之一

转到 运行和调试 选项卡，然后单击 开始调试 按钮，或者
只需按 F5。

4. 演练：使用 cuda-gdbserver 启动和调试在 QNX 主机上运行的远程应用程序

在以下演练中，我们将介绍您可能用于调试在 QNX 上运行的远程目标机器上基于 CUDA 的应用程序的一些更常见的过程。我们使用名为 Matrix Multiply 的示例应用程序作为示例。CUDA 工具包 CUDA 示例和 GitHub 上的 NVIDIA/cuda-samples 存储库包含此示例应用程序。

有关 DriveOS QNX 上支持的示例版本的信息，请参阅NVIDIA DRIVE 文档。

4.1. 打开示例项目并设置断点

在本地计算机上，

在 Visual Studio Code 中，打开 CUDA 示例中名为 matrixMul 的目录。

有关查找示例应用程序的帮助，请参阅使用示例。

注意：

此文件包含 CPU 代码（即 matrixMultiply()）和 GPU 代码（即 matrixMultiplyCUDA()，任何使用 __global__ 或 __device__ 关键字指定的函数）。

首先，让我们在 GPU 代码中设置一些断点。
1. 打开名为 matrixMul.cu 的文件，并找到 CUDA 内核函数 matrixMulCUDA()。
2. 在以下位置设置断点
```
int aStep  =  BLOCK_SIZE
```
3. 在以以下语句开头的行设置另一个断点
```
for {int a = aBegin, b = bBegin;
```
现在，让我们在 CPU 代码中设置一些断点
1. 在同一文件 matrixMul.cu 中，找到 CPU 函数 matrixMultiply()。
2. 在以下位置设置一个断点
```
if (block_size == 16)
```
3. 在以以下语句开头的行设置另一个断点：
```
printf("done\n"); 
```

4.2. 创建启动配置

为了调试我们的应用程序，我们必须首先创建一个启动配置。要创建 launch.json，首先转到 运行和调试 选项卡，然后单击 创建 launch.json 文件。

为环境选择 CUDA C++ QNX (CUDA-GDBSERVER)。

以下是为 CUDA 调试生成的启动配置

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "CUDA GDB Server: Launch",
            "type": "cuda-qnx-gdbserver",
            "request": "launch",
            "server": "cuda-gdbserver",
            "program": "",
            "target": {
                "host": "${config:host}",
                "port": "${config:port}"
            },
            "environment": [
                {
                    "name": "QNX_TARGET",
                    "value": ""
                },
                {
                 "name": "QNX_HOST",
                 "value": ""
                }
            ],
            "additionalSOLibSearchPath": "",
            "debuggerPath": ""
        }
    ]
}

在 launch.json 中，

将 program 属性更改为 ${workspaceFolder}/matrixMul，
将目标属性（主机和端口）设置为您将运行的 cuda-gdbserver 的主机和端口，
将 additionalSOLibSearchPath 设置为调试器搜索共享库的目录。
设置您需要的任何环境变量，并且
将 debuggerPath 设置为宿主机系统上 cuda-qnx-gdb 的路径。

注意：

${workspaceFolder} 是一个预定义变量，表示在 VS Code 中打开的文件夹的路径。

启动配置的其他可用属性包括

additionalSOLibSearchPath：调试器搜索共享库的目录。
args：传递给被调试程序debuggee的命令行参数。可以是字符串或数组。示例：“arg1”或 [“arg1”, “arg2”]。双重转义转义字符。示例：["{\\\"arg1\\\": true}"] 将向应用程序发送 {"arg1": true}。
breakOnLaunch：在每个启动的内核的第一条指令处中断。
cwd：被调试程序进程的当前工作目录 (cwd)。
debuggerPath：cuda-gdb 的路径。如果未指定，将搜索 cuda-gdb 的路径。
environment：包含指定环境变量的对象的数组。
envFile：包含 VAR=VALUE 行以指定环境变量的文件的绝对路径。
executableUploadPath：您要将可执行文件上传到的绝对路径（在 QNX 板上）。
initCommands：在启动 inferior 之前发送的 GDB 命令列表。
logFile：用于记录与 cuda-gdb 交互的文件的绝对路径。可以设置为 ${workspaceFolder}/myLogFile.txt，例如，启用 cuda-gdb 中的日志记录，以帮助客户支持找到遇到的任何问题的根本原因。可以使用 Nsight VSCE 开发者论坛上传日志文件。
miDebuggerArgs：在启动调试器（例如 cuda-gdb）时传递自定义命令行参数。示例：“miDebuggerArgs”: [“--quiet”]
miDebuggerPath：指定调试器（例如 cuda-gdb）的路径。示例：“miDebuggerPath”: “/usr/local/bin/cuda-gdb”。如果未指定，它将在操作系统的 PATH 变量中搜索 cuda-gdb。
onAPIError：指示在发生驱动程序 API 或运行时 API 错误时要执行的操作。有效值为 hide、ignore 和 stop。
program：要调试的程序的路径。
stopAtEntry：在被调试程序的第一条指令处中断。
sysroot：包含目标库副本的本地目录。
目标:
- Host：要连接的目标主机。
- Port：要连接的目标端口。
- Connect commands：要运行的命令。
verboseLogging：设置为 true 以生成详细的日志输出。

4.3. 构建示例

使用 https://developer.nvidia.com/docs/drive/drive-os/6.0.6/public/drive-os-qnx-installation/common/topics/installation/build-samples/build-run-sample-apps-qnx.html 中的说明交叉编译示例

4.4. 将 cuda-gdbserver 复制到远程机器并在远程机器上实例化它

在构建示例之后，我们使用预定义的自动启动任务将示例复制到远程机器并在远程机器上实例化 cuda-gdbserver。转到命令面板并执行 任务：配置默认构建任务 命令。

将列出多个任务选项，对于这种情况，您需要选择 Nsight：自动启动（安全复制 cuda-gdbserver 二进制文件，远程 QNX）。

以下是生成的任务配置

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Nsight: autostart (secure copy cuda-gdbserver binary, remote QNX)",
            "type": "shell",
            "command": "scp ${config:cudaGdbServerPath} ${config:username}@${config:host}:/tmp && ssh ${config:username}@${config:host} /tmp/cuda-gdbserver ${config:port}",
            "problemMatcher": [],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

此时，您可以替换 tasks.json 中 executable、username、host、port 的值，或者通过创建 settings.json 为它们提供值。建议您创建 settings.json，因为这样您也可以在 launch.json 中访问这些值。

如果您创建 settings.json，它将如下所示

{
    "version": "2.0.0",
    "tasks": [
        {
            "username": "uname",
            "host": "127.0.0.1",
            "port": "12345",
            "cudaGdbServerPath": "/usr/local/cuda-targets/aarch64-qnx/11.4/bin/cuda-gdbserver",
        }
    ]
}

要运行任务，请再次转到命令面板并运行 任务：运行构建任务 任务。查看问题和终端面板以查找错误消息。

要开始调试，请执行以下操作之一

转到 运行和调试 选项卡，然后单击 开始调试 按钮，或者
只需按 F5。

声明

_{NVIDIA® Nsight™ 异构平台应用程序开发环境 Visual Studio Code Edition 2024.1 用户指南}_发送反馈

_{本指南中的信息以及本指南中引用的 NVIDIA 文档中包含的所有其他信息均“按原样”提供。 NVIDIA 不对产品信息的准确性、完整性或质量做出任何明示、暗示、法定或其他方面的保证，并且明确否认所有关于产品信息不侵权、适销性和适用于特定用途的暗示保证。尽管客户可能因任何原因而遭受任何损害，但 NVIDIA 对本指南中描述的产品的客户的累计总责任应根据 NVIDIA 产品销售条款和条件进行限制。}

_{本指南中描述的 NVIDIA 产品不具有容错能力，并非设计、制造或旨在用于与以下任何系统的设计、建造、维护和/或操作相关的用途，在这些系统中，使用或此类系统的故障可能会导致威胁人类生命安全或严重人身伤害或财产损失的情况（包括但不限于与任何核能、航空电子、生命支持或其他生命攸关的应用相关的用途）。 NVIDIA 明确否认对此类高风险用途的任何明示或暗示的适用性保证。 NVIDIA 不对客户或任何第三方承担任何全部或部分责任，对于因该等高风险用途引起的任何索赔或损害赔偿。}

_{NVIDIA 不保证或声明本指南中描述的产品在未经进一步测试或修改的情况下适合任何特定用途。 NVIDIA 不一定会执行每个产品的所有参数的测试。客户全权负责确保产品适合客户计划的应用，并为应用进行必要的测试，以避免应用或产品的默认设置。客户产品设计的缺陷可能会影响 NVIDIA 产品的质量和可靠性，并可能导致超出本指南中包含的附加或不同条件和/或要求。 NVIDIA 不对任何可能基于或归因于以下原因的任何默认设置、损坏、成本或问题承担任何责任：(i) 以任何违反本指南的方式使用 NVIDIA 产品，或 (ii) 客户产品设计。}

_{除客户有权将本指南中的信息用于产品外，NVIDIA 特此未在本指南下授予任何其他明示或暗示的许可。只有在获得 NVIDIA 书面批准、未经修改地复制且附带所有相关的条件、限制和声明的情况下，才允许复制本指南中的信息。}

商标

_{NVIDIA、NVIDIA 徽标以及 cuBLAS、CUDA、CUDA-GDB、CUDA-MEMCHECK、cuDNN、cuFFT、cuSPARSE、DIGITS、DGX、DGX-1、DGX Station、NVIDIA DRIVE、NVIDIA DRIVE AGX、NVIDIA DRIVE Software、NVIDIA DRIVE OS、NVIDIA Developer Zone（又名“DevZone”）、GRID、Jetson、NVIDIA Jetson Nano、NVIDIA Jetson AGX Xavier、NVIDIA Jetson TX2、NVIDIA Jetson TX2i、NVIDIA Jetson TX1、NVIDIA Jetson TK1、Kepler、NGX、NVIDIA GPU Cloud、Maxwell、Multimedia API、NCCL、NVIDIA Nsight Compute、NVIDIA Nsight Eclipse Edition、NVIDIA Nsight Graphics、NVIDIA Nsight Integration、NVIDIA Nsight Systems、NVIDIA Nsight Visual Studio Edition、NVIDIA Nsight Visual Studio Code Edition、NVLink、nvprof、Pascal、NVIDIA SDK Manager、Tegra、TensorRT、Tesla、Visual Profiler、VisionWorks 和 Volta 是 NVIDIA Corporation 在美国和其他国家/地区的商标和/或注册商标。其他公司和产品名称可能是与其相关的各自公司的商标。}

声明

商标

版权