Registry#

Registry 是 Graph Composer 生态系统的组成部分，负责在扩展和工具之间提供统一的接口。可以使用 registry CLI 访问 Registry 服务

Registry 命令行界面

在后端，Registry 与 Nvidia 云存储库和本地工作区通信以进行扩展管理，同时它使用本地数据库作为扩展元数据的缓存。

存储库管理器#

存储库管理器负责根据操作或操作参数与 NVIDIA 云存储库或本地工作区进行通信。

NVIDIA 云存储库#

来自 Nvidia 的公共访问扩展发布在 Nvidia 云存储库中。外部用户可以使用 registry repo sync -n ngc-public 命令访问这些扩展。此命令将所有已发布的扩展元数据下载到本地磁盘上的缓存。

本地工作区#

本地工作区为扩展开发工作流程提供。Registry 将扩展的当前开发版本存储在本地工作区中。Registry 使用的默认工作区路径是 /var/tmp/gxf/.cache/gxf_workspace。它仅存储一个版本，因此每当用户更新扩展版本并将其添加到 registry 时，它都会被覆盖。

注意

/var/tmp/gxf/` 被视为本地磁盘上的 registry 根目录，可以使用 GXF_REGISTRY_ROOT 环境变量进行配置。

缓存#

Registry 维护从 Nvidia 云存储库同步或通过扩展开发工作流程在本地添加的所有扩展的元数据。它允许快速访问来自工具查询的扩展元数据。用户可以使用Registry 命令行界面命令清除缓存或刷新缓存。用户在清除缓存后必须再次同步存储库，才能从 registry 查询扩展信息。

Registry 维护两种类型的缓存。扩展元数据包含来自所有已同步扩展的扩展接口以及已上传到 NGC 的相应变体。此缓存由 registry 通过 registry repo sync 命令填充。扩展变体由 registry graph install 命令缓存。包含扩展库以及任何其他头文件、源文件或数据文件的变体存档在首次从 NGC 存储库下载时缓存，并为后续的 registry graph install 操作重用。

注意

/var/tmp/gxf/ 被视为 registry 根目录，可以使用 GXF_REGISTRY_ROOT 环境变量进行配置。或者，可以使用 registry cache --set 命令为 registry 缓存设置特定路径。

注意

如果 Composer 是从 Docker 启动的，则可以通过挂载 registry 缓存路径在 Docker 中访问主机的 registry 缓存。

Docker 启动的示例命令： :: docker run -it –rm –net=host –runtime nvidia -e DISPLAY=$DISPLAY -v /tmp/.X11-unix/:/tmp/.X11-unix -v /var/tmp/gxf/.cache/gxf_registry/:/var/tmp/gxf/.cache/gxf_registry/ –privileged <DOCKER-REPOSITORY>:<TAG>

扩展注册#

扩展注册将新扩展添加到 registry 的缓存和默认存储库。register_extension 宏可用于向 registry 注册新扩展。

必填字段

name - 扩展注册目标的名称。它必须遵循 register_<extension-name>_ext 命名约定。
extension – 使用 graph_cc_extension(…) 规则编译的扩展目标
uuid – 用于注册扩展的通用唯一标识符。格式应遵循标准uuid 约定
version – 扩展版本。一个字符串，用于指定扩展的版本，格式为 MAJOR.MINOR.PATCH。扩展开发人员应遵循语义版本控制概念，其中版本的新更新应遵循以下准则
- 当存在 API 破坏性更改时，MAJOR 版本更新
- 当以向后兼容的方式添加功能时，MINOR 版本更新
- 当以向后兼容的方式修复错误时，PATCH 版本更新
license – 扩展许可证。一个字符串，用于命名与扩展关联的许可证类型。例如 – MIT、Apache-2.0、BSD。
license_file – 指向包含完整许可条款和规范的文本文件的路径。

可选字段

url – 指向扩展项目网址的链接
repository – 指向扩展源代码网址的链接
labels – 可用于在 NGC 中对扩展进行分类的字符串列表。例如，[“nvidia”, “gpu”, “nvgraph”]
priority – 介于 0-100 之间的值，用于指示部署期间要使用的扩展的优先级。
target – 扩展变体的目标配置。一个字典，包含以下键 - arch、os 和 distribution。如果未指定目标信息，则将根据使用的 bazel 构建配置自动推断。接受的值
- arch – x86_64、aarch64、sbsa
- os – linux
- distribution – ubuntu_22.04
local_dependencies – 依赖存储库的注册目标列表。此处指定的扩展将在当前扩展之前注册。例如
```
local_dependencies = ["//gxf/sample_extension:register_sample_ext"]
```
compute_dependencies – 构建扩展库所需的计算依赖项列表。这些计算依赖项的所需版本将使用使用的 bazel 构建配置自动推断。接受的值 - cuda、cudnn、tensorrt、deepstream、vpi。用法示例
```
compute_dependencies = ["cuda", "tensorrt", "deepstream"]
```
headers – 包含扩展头文件路径的字符串列表。
binaries – 包含扩展在部署期间需要的任何可选二进制文件路径的字符串列表。
data – 包含扩展在部署期间需要的任何可选数据文件路径的字符串列表。

一旦调用 register_extension 宏，将自动生成清单文件，并且 registry CLI 工具将用于运行 extn add 命令以及相应的参数。此规则进一步将此扩展添加到 registry 的本地缓存，并使用扩展库、清单、元数据以及注册期间指定的任何可选文件来更新默认存储库。注册过程还会生成一个输出文件，其中包含有关扩展接口的元数据。更具体地说，它包含有关各种组件和这些组件中使用的参数、头文件、依赖项、标签、作者、描述等的信息。

以下是注册扩展的准则

x86_64 版本的扩展必须在注册任何交叉编译 (aarch64) 变体之前首先注册。由于无法查询交叉编译扩展的扩展接口（组件和参数类型），因此 registry 将 x86_64 版本的扩展视为其接口的参考。如果自上次注册扩展以来缓存和/或默认存储库已被清除，则必须再次注册 x86_64 版本的扩展以重新填充缓存和默认存储库。

如果正在注册的扩展依赖于源代码中的其他扩展，则必须将其列为“dependencies”字段中的依赖项。具体而言，依赖扩展的注册目标名称必须列为依赖项，以便 registry 可以查询依赖扩展的元数据以获取其 uuid、名称和版本。

如果同一扩展变体注册了两次，则默认存储库中先前注册的变体将被删除，并使用新清单中的内容进行更新。同样，注册任何 x86_64 变体都将更新 registry 缓存中的扩展接口，因此重要的是，扩展接口在同一扩展和版本的所有变体中保持不变。

仅 Linux x86_64 平台支持注册扩展及其变体。

安装用于部署的图#

registry 还可以用于在本地部署图或使用容器构建器容器化图。为了使用 gxe 执行图，registry 提供了一个功能来准备清单和包含所有所需扩展的相应存档包。

此处显示了上面示例图的示例清单

此处显示了上面示例图的示例存档

要安装图

使用 nvgraph composer 创建图并将其保存到本地文件系统。
在 CLI 工具中使用 graph install 命令以及目标平台配置，该配置决定了应使用哪个扩展变体进行部署。Registry 将根据目标平台自动选择每个扩展的最佳匹配变体。
graph install 命令的输出是一个 gxe 清单以及一个存档，其中包含所有扩展库和与扩展变体一起打包的文件。
可以选择在本地目录中解压缩部署包，该目录可用于在本地运行图。将 registry CLI 工具与 graph install --help 一起使用以查看支持的所有参数。
图中使用的所有扩展都必须存在于 registry 的本地缓存中才能成功安装图。图中使用的扩展版本也必须与 registry 缓存中找到的扩展版本匹配。
假设扩展 A 被列为扩展 B 和扩展 C 的依赖项。如果使用扩展 B 和扩展 C 创建图，则需要确保 B 和 C 都依赖于相同版本的扩展 A，并且该版本的扩展 A 应与 registry 同步以安装图。不支持在一个图中使用同一扩展的多个版本，也不建议创建此类依赖项。
registry 在安装图时执行版本管理，以确保部署最新版本的扩展。假设图是使用 1.0.0 版本的扩展 A 创建的，而在 graph install 阶段有较新版本的扩展 1.1.0 可用。确保仅将与扩展的同一主要版本对应的最新 minor.patch 版本添加到存档中。