当前位置：首页 > ai >正文

整理几个概念：DCU DTK HIP hipcc ROCm LLVM Triton MIGraphX 怎么增加GStreamer插件

ai 2025/6/28 3:07:26

1 引言

2 DCU (Device Compute Unit，类 GPU 加速单元）

2.1 什么是DCU

2.2 架构上的 DCU（对标 NVIDIA SM）

2.3 工程中的 DCU：国产 GPU/加速卡的别名

2.4 DCU的软件栈配套

2.5 与 NVIDIA CUDA 平台对比

3 DTK (Device ToolKit，设备上的统一工具链）

3.1 什么是 DTK？

3.2 DTK 提供哪些核心功能？

3.3 使用 DTK 的典型场景

3.4工程开发建议

3.5 疑问：DTK到底是个命令，还是驱动，还是一堆库里面包含被调用的API，

3.6 疑问：DTK里面有模型推理的api吗

3.7 疑问：DTK里面有申请设备内存的api吗

4 HIP (与 CUDA 类似的跨平台 GPU 编程接口)

4.1 HIP 与 CUDA 的关系

4.2 hip编写的程序，后缀是什么

5 hipcc (HIP 编译器前端)

5.1 什么是hipcc

5.2 hipcc的作用

5.3 疑问：hipcc其实不是具体的编译器，对吗，她在amd上面会调用clang，在英伟达平台上会调用nvcc，对吗

6 ROCm

6.1 什么是 ROCm？

6.2 ROCm 的核心组件

6.3 ROCm 的定位与特性

6.4 疑问：那么其实rocm就是amd搞得一套东西，包含各种工具，编译器，库，驱动，就是和英伟达的那一套什么cuda,cudnn,类似的，这么理解可以吧

7 LLVM

7.1 什么是LLVM

7.2 llvm的核心组成

7.3 LLVM 的工作流程（编译原理）

7.4 为什么 LLVM 很重要？

7.5 常见使用 LLVM 的项目

7.6 总结

7.7 疑问：怎么理解LLVM，那么即时说比如现在我有一个国产的DCU吧，然后我想创建一个这个DCU上面的编译器，那么就可以基于llvm这个底座或者说框架，然后写一个或者发明一个我这个dcu上面的具体编译器，可以这么理解吗

7.8 疑问：最后自己写一套后端 backend，将 LLVM IR 转换为你这个 DCU 能执行的指令集。这个具体是做什么

7.8.1 指令选择（Instruction Selection）

7.8.2 指令调度与寄存器分配（Scheduling & Register Allocation）

7.8.3 汇编输出与指令编码（Assembly & Emission）

8 Triton Inference Server：通用推理部署平台

8.1 什么是 Triton Inference Server？

8.2 Triton 的核心特点

8.3 个人理解

9 MIGraphX（高性能异构推理引擎）--其实就是国产DCU上面类似TensorRT的东西

9.1 什么是 MIGraphX？

9.2 MIGraphX 的核心功能

9.3 MIGraphX 的工作流程

9.4 MIGraphX 与其他组件的关系

9.5 为什么选择 MIGraphX？

9.6 总结

9.7 个人理解--国产 DCU 平台上类似 TensorRT 的高性能推理引擎

9.8 MIGraphX与onnxruntime的关系

10 GStreamer

10.1 什么是 GStreamer？

10.2 GStreamer 的核心概念

10.3 GStreamer 的架构

10.4 GStreamer 与国产异构计算平台结合

10.5 个人理解：那么gstreamer其实就是一个pipeline架构编写的工程代码，然后内部是可以处理从视频解码--处理--视频编码的这样一个流程的，然后里面包含很多个element，我可以这么理解吗，

10.6 疑问：如果在国产cpu上，我们是不是可以把硬件编解码封装成一个插件然后加载到gstreamer上面，对吧

10.7 编写插件的疑问

10.7.1 插件以 .so 形式放入 GStreamer 插件搜索路径（比如 /usr/lib/gstreamer-1.0/）

10.7.2 每个插件 .so 中都必须包含一个宏

10.7.3 GStreamer 内部会调用你提供的 plugin_init() 函数

11 DeepStream

11.1 什么是 DeepStream？

11.2 DeepStream 的核心特点

11.3 疑问：deepstream是英伟达根据gstream架构模仿的，还是说直接就是在gstreamer代码的基础上直接修改的

DeepStream 和 GStreamer 的关系是“插件 + 封装”，而不是“魔改”：

11.4 个人理解

1 引言

在看一些文档的时候，出现了一些名词，写一篇博客笔记整理一下。

2 DCU (Device Compute Unit，类 GPU 加速单元）

2.1 什么是DCU

DCU（Device Compute Unit） 是指异构计算平台中用于执行并行计算任务的核心计算单元。在国产 GPU 或 AI 加速平台中，DCU 通常承担深度学习推理、图像处理、视频编解码等高性能任务的执行。

在不同上下文中，“DCU”具有不同的含义：

架构层面：DCU 表示芯片中承担实际计算的基本单元，类似 NVIDIA 的 SM（Streaming Multiprocessor）或 AMD 的 CU（Compute Unit）。
工程层面：“DCU”常作为整块“国产异构加速卡”的统称，用来替代传统 NVIDIA GPU。

2.2 架构上的 DCU（对标 NVIDIA SM）

在硬件架构层面，DCU 是设备内部负责并行运算的模块，包含多个执行单元、寄存器组、本地缓存、调度器等子系统。其功能与 NVIDIA GPU 中的 SM 类似。

构件对比	国产平台 DCU	NVIDIA 平台 SM
执行核心	多个向量/矩阵计算单元	CUDA cores / Tensor cores
本地资源	寄存器、共享内存、本地缓存	共享内存、L0 cache、warp schedulers
调度方式	Wavefront / SIMD / block	Warp-based 执行
所属架构	海光 DCU、寒武纪 MLU Core、昇腾 AI Core

2.3 工程中的 DCU：国产 GPU/加速卡的别名

在实际工程项目中，比如内部项目里，“DCU”往往并不是只指某个芯片内的模块，而是指整张异构加速卡，比如：

“上了 4 张 DCU” = “上了 4 张国产 GPU 卡”

这种叫法源于工程需求：

“GPU”是 NVIDIA 的商标词，不适合在国产平台直接使用；
“AI卡”、“MLU卡”、“XPU”叫法不统一；
因此统一称作“DCU”，即 Device Compute Unit。

你可以理解为：

在国产异构平台，DCU ≈ 国产 GPU ≈ 计算加速卡

2.4 DCU的软件栈配套

配合 DCU 使用的软件工具链包括：

软件名称	说明
DTK（Device ToolKit）	设备管理工具包，提供设备枚举、调度、资源分配等功能
HIP	类似 CUDA 的异构并行编程语言
MIGraphX	高性能推理框架，支持将 ONNX 模型部署到 DCU 上
Triton	可通过 DTK 插件支持 DCU 设备

其中，HIP + MIGraphX 是使用 DCU 进行模型推理的主要方式。

2.5 与 NVIDIA CUDA 平台对比

对比维度	国产平台	NVIDIA 平台
设备名	DCU	GPU
计算单元	DCU Core / SIMD	SM（Streaming Multiprocessor）
编程接口	HIP、DTK、MIGraphX	CUDA、cuDNN、TensorRT
调度方式	Block / Wavefront	Block / Warp
使用方式	单独卡 / 内嵌 SoC	显卡或集成 GPU

3 DTK (Device ToolKit，设备上的统一工具链）

3.1 什么是 DTK？

DTK（Device ToolKit） 是某国产异构计算平台提供的一套设备管理与调度工具包，主要用于：

查询和管理本地系统中的异构加速设备（如 DCU）
监控设备运行状态与资源使用情况
支持模型推理框架（如 Triton）将任务部署到加速卡上

你可以把它理解为 国产平台版的 NVIDIA Management Library（NVML）+ CUDA Driver API 的组合，但更贴近平台特定硬件架构。

3.2 DTK 提供哪些核心功能？

DTK 提供了一套编程接口（API）和命令行工具，核心能力如下：

功能类别	具体内容
设备管理	查询设备数量、类型、内存大小、版本信息
资源监控	获取设备温度、电压、功耗、运行状态、利用率
任务控制	查询或控制设备当前任务运行情况
异构调度	为模型推理或计算任务动态分配目标 DCU
与推理框架对接	支持与 Triton、MIGraphX 等推理框架无缝集成

3.3 使用 DTK 的典型场景

DTK 的设计目标是为上层 AI 推理/图像处理/视频编解码框架提供统一的底层设备调度与管理支持。常见应用包括：

集群部署场景：

利用 DTK 查询每个节点上空闲的 DCU 数量，自动分配资源部署推理任务。
Triton Inference Server 接入：

通过 DTK 插件将国产设备注册为 Triton 后端设备，实现多模型并发推理。
性能监控：

在上线推理系统时实时监控设备利用率与温度，防止资源过载。
模型精调与调度测试：

使用 DTK 控制推理运行在哪块设备上，做对比实验与性能分析。

3.4工程开发建议

在开发国产异构平台上的推理系统或多模型服务框架时，推荐使用 DTK 来完成：

初始化设备并动态分配资源
绑定推理任务与物理卡
实现任务超时/掉电/负载均衡处理逻辑
搭建监控面板对接 Prometheus / Grafana

DTK 已成为在国产平台上进行推理部署的“标准管理中间件”。

3.5 疑问：DTK到底是个命令，还是驱动，还是一堆库里面包含被调用的API，

DTK（Device ToolKit）本质上是一套用于管理国产异构计算设备（DCU）的：

工具链 + 库 + API 接口的组合体，
它包括命令行工具（像 dtk-smi）、动态链接库（.so 文件）、头文件（.h）、开发文档和示例代码，既可以用于开发，也可以用于运维管理。

组成	本质	用途
✅ 动态链接库（libdtk.so）	一个 `.so` 文件	提供给 C/C++ 程序调用，用于获取设备状态、控制任务分配等
✅ C/C++ 头文件（dtk.h）	一组 `.h` 文件	用来声明 DTK 的 API 函数，供开发者集成
✅ 命令行工具（dtk-smi）	可执行程序	类似 `nvidia-smi`，用于查看设备状态、性能、任务等
✅ Python/封装接口（可能有）	封装层或 bindings	有的平台可能提供 Python 接口，方便脚本化调用
✅ 示例代码和文档	Markdown / PDF	教你怎么用 DTK 调 API、查看设备等

3.6 疑问：DTK里面有模型推理的api吗

DTK 本身并不提供模型推理的 API，也就是说：不能直接用 DTK 来做模型推理，它的职责是设备管理，不是“跑模型”。

功能	是否属于 DTK
查询有几块 DCU	✅ 是
获取每块 DCU 的内存、温度、利用率	✅ 是
控制某个推理任务部署在哪块卡上	✅ 是（间接）
加载模型 / 推理 ONNX / 获取输出张量	❌ 不是
模型精度配置 / 动态 batch 推理 / 通道复用	❌ 不是

模型推理需要用下面的模块或者框架

组件	职责	和 DTK 的关系
HIP	提供异构编程语言接口（像 CUDA）	DTK 可以查询设备信息供 HIP 程序绑定
MIGraphX	高性能 ONNX 推理引擎	DTK 提供设备抽象层，MIGraphX 运行时调用
Triton Inference Server	推理服务框架，支持多模型/多设备	可以通过 DTK 插件调度国产 DCU
自研 Runtime	某些公司可能有自己的推理库	同样基于 DTK 查询设备或控制上下文

3.7 疑问：DTK里面有申请设备内存的api吗

DTK 的 API 里确实包含了访问/查询设备显存（DCU 显存）信息的接口。TK 提供了“查询显存状态”的接口，但不负责真正分配和操作显存数据。真正分配显存、拷贝数据、执行推理，仍是 HIP/MIGraphX/Triton Runtime 的工作。DTK 的作用是“让你知道显存用多少了”，“能不能分资源给下一个任务”，是调度辅助工具，不负责实际 malloc 或运行。

4 HIP (与 CUDA 类似的跨平台 GPU 编程接口)

一句话理解：HIP（Heterogeneous-Compute Interface for Portability）就是一个跨平台的并行计算编程框架，类似 CUDA，但支持多种硬件架构，不仅仅局限于 NVIDIA GPU。

HIP 是一种用于异构计算的编程接口（API），由 AMD 主导开发，旨在实现跨平台的 GPU 计算能力。它让开发者可以编写类似 CUDA 风格的代码，但不仅支持 NVIDIA GPU，也支持 AMD GPU 以及其他兼容设备。

简单来说，HIP 就像是 CUDA 的“跨平台版本”，你用 HIP 写的代码，可以更方便地在不同厂商的 GPU 硬件上运行，而不必为每种硬件单独改写代码。

4.1 HIP 与 CUDA 的关系

HIP 的编程模型和语法与 CUDA 非常相似，便于 CUDA 程序员快速上手。
HIP 提供了从 CUDA 到 HIP 的自动转换工具 hipify，帮助将现有 CUDA 代码移植。
在底层，HIP 会调用对应平台的驱动和运行时，抽象出统一的接口。

HIP 就是“跨平台版的 CUDA”

语法风格几乎和 CUDA 一样：线程块、线程索引、核函数定义等基本一致，CUDA 程序员可以无缝上手。
支持跨厂商 GPU：不仅能跑在 AMD GPU 上，一些国产异构平台也在兼容 HIP，未来也可能扩展到更多架构。
可以和 CUDA 代码互转：AMD 提供了工具（如 hipify）可将 CUDA 代码自动转为 HIP 代码，迁移成本低。
运行时与底层调用不同：虽然语法类似，但 HIP 会根据平台（如 ROCm、CUDA）调用不同的驱动和库。

4.2 hip编写的程序，后缀是什么

UDA 程序的源文件通常使用 .cu 后缀，比如 kernel.cu，这是因为 NVIDIA 的 nvcc 编译器会识别 .cu 并进行 CUDA 编译。

而 HIP 程序的源文件后缀也 通常仍然使用 .cu 或 .cpp，没有强制要求使用新的后缀。常见约定如下：

文件后缀	用途说明
`.cpp`	通用 C++ 文件，适用于 host 端逻辑，也可包含 HIP 核函数定义（由 hipcc 编译）
`.cu`	如果是从 CUDA 迁移过来的项目，保留 `.cu` 后缀也没问题，`hipcc` 照样能编译
`.hip`（少见）	有些项目为了区分 HIP 文件，也自定义用 `.hip`，但并不标准

5 hipcc (HIP 编译器前端)

5.1 什么是hipcc

hipcc 是 HIP 平台提供的 命令行编译器工具，作用类似于 NVIDIA 平台上的 nvcc，它用于将 HIP 编写的源代码（如 .cpp 或 .cu）编译为目标平台（如 AMD GPU、国产 GPU 等）可执行的二进制程序。

你可以把它理解为：

一个“跨平台的 CUDA 编译器封装器”，可以根据平台差异，自动调用底层的实际编译器，完成 HIP 程序到设备代码的转换。

5.2 hipcc的作用

编译 HIP 核函数和 C++ 代码
自动链接相关库（hip runtime、device libs 等）
根据目标平台，调用不同的底层编译工具
- 在 AMD ROCm 上，调用 clang++ 和 HIP runtime。
- 在国产平台上，调用定制化的后端（如支持 DCU 的 HIP backend）。
- 在 NVIDIA 上，也可调用 nvcc（作为 HIP CUDA backend）。

5.3 疑问：hipcc其实不是具体的编译器，对吗，她在amd上面会调用clang，在英伟达平台上会调用nvcc，对吗

hipcc 本质上不是一个真正的编译器，它是一个 编译器包装器（wrapper），类似一个智能的中间脚本，根据你所处的平台去 自动调用真正的底层编译器。

工作机制如下：

平台	hipcc 实际调用的底层编译器
AMD ROCm 平台	调用 `clang++`（HIP-clang）
NVIDIA 平台	调用 `nvcc`（NVIDIA CUDA 编译器）
国产平台（如 DCU）	调用平台定制化的 `clang` 或其他后端
其他平台（假设支持）	可能调用平台适配的 LLVM 工具链

hipcc 主要做了这些事：

根据环境变量（如 HCC_AMDGPU_TARGET、HIP_PLATFORM）识别当前平台
设置好 include 路径和 lib 路径（比如 HIP runtime、device libs）
统一封装编译参数（你只需要像用 g++ 那样用它）
自动选用 clang++、nvcc 或其他后端编译器执行实际编译工作

hipcc my_kernel.cpp -o my_kernel

如果你在 AMD GPU（ROCm）环境下执行，它会底层调用 clang++ 编译。
如果你在 NVIDIA GPU 环境下执行，它会自动调用 nvcc。
如果你在某国产平台（如 DCU）上，调用的是该平台定制的 clang 工具链（假设已注册为 HIP backend）。

hipcc 是 HIP 提供的跨平台统一编译入口，它本身不做实际编译工作，而是根据平台环境调用真正的底层编译器（如 clang、nvcc、国产定制 clang 等）。

6 ROCm

6.1 什么是 ROCm？

ROCm（Radeon Open Compute） 是 AMD 推出的开源异构计算平台，全称为 Radeon Open Compute Platform，旨在为 GPU 提供高性能、可扩展的计算环境。

你可以把它理解为：

AMD 提供的 “CUDA 平台” 替代方案，是面向 HPC（高性能计算）和 AI 领域的一整套软硬件协同生态。

ROCm 支持包括：

编译器（基于 LLVM）
编程模型（HIP、OpenCL、OpenMP）
GPU 驱动
运行时（ROCr）
库（BLAS、FFT、DNN 等）

6.2 ROCm 的核心组件

模块	描述
HIP	高级 C++ API，兼容 CUDA 编程模型，具备跨平台能力
ROCr runtime	运行时库，负责管理 GPU 上的任务调度、内存分配、上下文等
ROCm kernel driver	支撑 ROCm 的低层驱动，负责与 GPU 设备直接通信
hsa-runtime	HSA（异构系统架构）运行时，为硬件资源管理提供统一抽象
rocBLAS / MIOpen	提供线性代数（BLAS）、深度学习（DNN）等高性能计算库
hipcc	HIP 编译器前端，根据平台调用 `clang` 或 `nvcc` 等
ROCm-SMI	类似 `nvidia-smi` 的监控工具，查询 GPU 状态、功耗、温度等

6.3 ROCm 的定位与特性

ROCm 的主要特点：

开源开放：源码完全开放，便于社区优化和定制
面向 HPC / AI：针对数据中心、大规模计算环境优化
多语言支持：支持 HIP / OpenCL / OpenMP 等多种模型
高性能数学库：涵盖 DNN、BLAS、FFT 等多种标准库
跨平台编程：可与 HIP 结合实现 CUDA 与 AMD 设备的代码兼容

6.4 疑问：那么其实rocm就是amd搞得一套东西，包含各种工具，编译器，库，驱动，就是和英伟达的那一套什么cuda,cudnn,类似的，这么理解可以吧

是的，你这么理解完全正确。

可以简洁地说：

ROCm 就是 AMD 搞的一整套 GPU 计算生态系统，从编译器、驱动、工具链到各种数学库、深度学习库，全都包括在内，目的就是对标 NVIDIA 的 CUDA 生态。

具体对比如下：

对象	NVIDIA 体系	AMD ROCm 体系
编程语言	CUDA C/C++	HIP（兼容 CUDA）、OpenCL、OpenMP 等
编译器工具链	`nvcc` + CUDA Toolkit	`hipcc` + ROCm Toolkit（基于 LLVM/Clang）
数学库	cuBLAS、cuDNN、cuFFT 等	rocBLAS、MIOpen、rocFFT 等
驱动	NVIDIA Driver	ROCm Kernel Driver + ROCr Runtime
运行时	CUDA Runtime / Driver API	ROCr + HSA Runtime
设备监控工具	`nvidia-smi`	`rocm-smi`

所以你可以非常直白地说：

ROCm 就是 AMD 版本的 CUDA 平台，只不过是完全开源的，基于 LLVM 搭建的。

7 LLVM

7.1 什么是LLVM

LLVM 全称是 Low Level Virtual Machine，但现在已经不再是字面意义的“虚拟机”了。

你可以把它理解为：

一套模块化、可重用的编译器基础架构，能够帮助开发者构建支持多平台的编译器或工具链。

简单说，LLVM 不是一个编程语言，也不是编译器本身，而是一套编译器“构建工具箱”。

7.2 llvm的核心组成

模块	说明
`LLVM IR`	中间表示语言，是 LLVM 的核心。类似于汇编的中间代码，跨平台、中立，编译器中间阶段用它
`clang`	基于 LLVM 的 C/C++/Objective-C 前端编译器，广泛用于 macOS、ROCm、HIP
`LLVM backend`	将 LLVM IR 编译成具体硬件平台（x86、ARM、DCU 等）的机器码
`opt`	LLVM 的优化模块，对中间代码做高性能优化
`llc`	把 LLVM IR 变成底层汇编代码
`libLLVM`	C++ 语言封装的库，用于构建自定义编译器或静态分析器

7.3 LLVM 的工作流程（编译原理）

假设你写了一段 C++ 代码，在用 clang 编译时会发生如下过程：

int add(int a, int b) {return a + b;
}

编译过程如下：

源码 → clang frontend → LLVM IR → 优化器(opt) → 汇编代码(backend) → 二进制

如果用 LLVM 工具链，可以拆分成：

clang -S -emit-llvm test.cpp -o test.ll     # 得到 LLVM IR 文件
opt -O3 test.ll -o optimized.ll              # 对 IR 做优化
llc optimized.ll -o test.s                   # 转成目标平台汇编

7.4 为什么 LLVM 很重要？

跨平台：写一套 IR，然后就能支持多种硬件后端（x86/ARM/AMD GPU/DCU/...）。
易集成：适合用于自定义 DSL、AI 框架的编译优化、GPU 平台的指令适配。
性能优化强大：现代语言编译器（如 Rust、Swift）、AI 框架（TVM、XLA）、GPU 平台（ROCm、HIP）都基于 LLVM 做底层优化。

7.5 常见使用 LLVM 的项目

项目	用途
Clang	LLVM 的官方 C/C++ 编译器
Rust	Rust 编译器底层使用 LLVM
Swift	Apple 开发的语言，使用 LLVM
ROCm/HIP	AMD GPU 平台编译工具链
TVM/XLA	AI 模型编译优化器
国产平台的定制clang	国产 GPU 编译器也往往是 LLVM 定制出来的

7.6 总结

LLVM 就像是一个“万能编译器底座”，你想为自己的平台、语言做编译器、优化器或者代码生成器，LLVM 是你的最佳选择。

7.7 疑问：怎么理解LLVM，那么即时说比如现在我有一个国产的DCU吧，然后我想创建一个这个DCU上面的编译器，那么就可以基于llvm这个底座或者说框架，然后写一个或者发明一个我这个dcu上面的具体编译器，可以这么理解吗

是的，你这个理解非常准确！可以这样说：

LLVM 本质上是一套“编译器基础设施框架”，它不像传统意义上的编译器那样“只能编译程序”，而是提供了一整套“构建你自己的编译器”所需的模块和工具。

举个例子来说明：

你有一款 国产 DCU 加速卡，你想让它能编译并运行异构计算程序：

你不需要 从零开发 一个编译器（那是几十人年级别的工作）；
你可以 基于 LLVM 提供的中间表示（IR）和模块：
- 利用 LLVM 的前端（比如重用 Clang 支持的 C/C++ 语法）；
- 使用 LLVM 的中端优化器（几十种成熟的优化 passes）；
- 最后自己写一套 后端 backend，将 LLVM IR 转换为你这个 DCU 能执行的指令集

阶段	工作内容	LLVM 是否提供
前端 Frontend	语法解析成 IR（如 Clang）	✅
中端 Midend	优化（如 Loop unrolling, inlining）	✅
后端 Backend	IR 生成目标架构代码（如 DCU 指令）	❌ 你需要写的！

7.8 疑问：最后自己写一套后端 backend，将 LLVM IR 转换为你这个 DCU 能执行的指令集。这个具体是做什么

LLVM 编译器在前端（比如 Clang）把 C++、HIP、CUDA 等高级代码转换成 LLVM IR（中间表示），但这个 IR 是抽象的，不是特定硬件能执行的。

%1 = add i32 %a, %b

这只是“两个整数相加”，没有告诉你这条加法怎么映射到你的 DCU 的寄存器、指令格式、执行单元。后端的核心任务：让 LLVM IR 跑在你的硬件上！你可以把“写一个后端”理解成三个主要阶段：

7.8.1 指令选择（Instruction Selection）

把 LLVM 的 IR 映射成你 DCU 的硬件指令，你要告诉 LLVM：“这个 %1 = add i32 %a, %b” 对应我的硬件里的哪一条汇编，比如：

ADD R1, R2, R3   // 假设你的 DCU 是这种格式

你需要用 pattern matching 描述语言（TableGen） 配置这套转换规则。

7.8.2 指令调度与寄存器分配（Scheduling & Register Allocation）

指定指令执行顺序、给每条指令分配寄存器

LLVM 会帮你把虚拟寄存器映射成真实的 DCU 寄存器，比如：
- %1 最终用物理寄存器 R5
你还可以指定：
- 哪些指令是 流水线、哪些要 延迟槽
- 哪些寄存器是 专用的控制寄存器/浮点寄存器

7.8.3 汇编输出与指令编码（Assembly & Emission）

把调度后的指令输出成机器码（binary），或者汇编（.s）

比如你的 DCU 指令集是：
- ADD 编码是 0x01
- MUL 编码是 0x02
你要写指令编码规则，让 LLVM 把中间的表示翻译成真正的二进制，比如：

0x01 0xA2 0xB1 0xC3  // 加法，三个操作数编号

8 Triton Inference Server：通用推理部署平台

8.1 什么是 Triton Inference Server？

Triton Inference Server 是一个由 NVIDIA 开发的高性能推理服务器框架，用于部署各种深度学习模型，并支持多种后端（如 TensorRT、ONNX Runtime、PyTorch、TensorFlow 等）以及多模型并发执行和动态资源调度。

虽然最初由 NVIDIA 设计用于 GPU 推理，但 Triton 已逐渐演化为通用的模型推理服务器，在国产异构平台上也有适配和使用。

你可以把它理解为：

一个“模型推理服务器软件”，你可以把它部署在服务器上，接收 HTTP/gRPC 请求，对输入数据进行推理，然后返回结果。

8.2 Triton 的核心特点

特性	说明
多后端支持	支持 TensorRT、PyTorch、TensorFlow、ONNX Runtime、OpenVINO 等
多模型并发	可在一台设备上同时部署多个模型，支持动态加载/卸载
多设备调度	支持多 GPU / 多 DCU 设备的自动调度、负载均衡
高性能	异步执行、批处理优化、模型实例复用机制
易集成	提供 HTTP / gRPC 接口，支持与 Kubernetes、Prometheus、Grafana 集成
自定义后端	可扩展支持国产硬件平台，如集成 DTK 设备调度、MIGraphX 推理库等

8.3 个人理解

9 MIGraphX（高性能异构推理引擎）--其实就是国产DCU上面类似TensorRT的东西

9.1 什么是 MIGraphX？

MIGraphX 是一款由某国产异构计算平台提供的高性能深度学习推理引擎，专门针对自家的异构加速器（比如 DCU）进行了深度优化。它主要负责将深度学习模型（如 ONNX 格式）转换为硬件能高效执行的计算图，并利用底层硬件加速特性快速完成推理任务。

简单理解，MIGraphX 就像是国产平台上的 TensorRT，是一个针对特定硬件深度定制的模型推理库。

9.2 MIGraphX 的核心功能

功能类别	具体说明
模型加载	支持加载 ONNX、ONNX Runtime 导出的模型格式
图优化	对模型计算图进行层融合、算子优化、图剪枝等高效变换
硬件调度	根据底层硬件资源动态调度计算任务，提升推理吞吐量
量化支持	支持 INT8 等低精度量化推理，兼顾速度和精度
异构加速	利用 DCU 专用硬件指令和并行计算单元加速模型推理
多模型并发	支持多模型、多请求并发执行，提升资源利用率

9.3 MIGraphX 的工作流程

模型转换
首先，MIGraphX 将 ONNX 格式的模型文件解析成计算图（Graph IR）。
图优化与融合
对计算图进行多轮优化，例如算子融合（Conv + BN + ReLU）、去除冗余节点、算子替换为更高效版本等。
代码生成
通过针对异构硬件的代码生成后端，把高层计算图转换成 DCU 能执行的机器码或指令序列。
推理执行
调度异构硬件资源执行推理任务，完成前向计算，输出结果。

9.4 MIGraphX 与其他组件的关系

DTK：MIGraphX 通过 DTK 提供的设备管理接口获取硬件资源状态，调度任务到对应的 DCU。
Triton Inference Server：MIGraphX 常作为 Triton 的后端推理引擎之一，负责具体推理执行。
HIP：MIGraphX 底层代码可能基于 HIP 编写，确保跨平台异构计算能力。
ONNX Runtime：MIGraphX 可以看作是针对国产平台优化的 ONNX Runtime 变体，专注于高性能。

9.5 为什么选择 MIGraphX？

针对特定国产异构硬件深度优化，性能远超通用推理框架。
支持主流模型格式，易于接入现有 AI 训练流水线。
与国产硬件设备管理层（DTK）无缝集成，方便资源管理和调度。
支持丰富的模型优化技术，提升推理效率和吞吐量。

9.6 总结

MIGraphX 是国产异构计算平台上的核心推理引擎，类似于英伟达生态中的 TensorRT。它以支持高效的模型加载、图优化和硬件调度为目标，帮助开发者充分发挥 DCU 等加速器的性能优势，构建高吞吐、低延迟的推理服务。

9.7 个人理解--国产 DCU 平台上类似 TensorRT 的高性能推理引擎

9.8 MIGraphX与onnxruntime的关系

10 GStreamer

10.1 什么是 GStreamer？

GStreamer 是一个开源的跨平台多媒体框架，主要用于构建流媒体处理管道。它允许用户通过拼接各种插件，实现音视频数据的捕获、编码、解码、转码、复用、解复用、过滤和播放等功能。

简而言之，GStreamer 就像是“多媒体数据处理的积木盒子”，你可以用它搭建各种复杂的音视频处理流程。

10.2 GStreamer 的核心概念

概念	说明
Pipeline	数据流的整体管道，连接多个处理单元。
Element	管道中的单个功能单元（插件），例如解码器、编码器、滤镜等。
Pad	Element 的接口，用于连接上下游 Element 进行数据传输。
Bus	管理消息传递的机制，处理事件、错误、状态变化等。

10.3 GStreamer 的架构

GStreamer 通过插件机制实现功能扩展，插件分类主要有：

Source：数据来源，如文件、摄像头、网络流。
Filter：处理数据的元素，如解码、编码、变换。
Sink：数据输出，如音频播放设备、文件保存、网络发送。

应用程序通过构建 Pipeline，把 Source、Filter、Sink 等 Element 连接起来，完成音视频处理流程。

10.4 GStreamer 与国产异构计算平台结合

在国产异构平台上，GStreamer 常被用于音视频的采集和处理，结合国产加速卡的推理能力，可实现智能视频分析、边缘计算、实时编码和解码加速等。

例如：

利用国产 DCU 加速视频解码和编码
通过 GStreamer Pipeline 插入 AI 推理模块，实现智能检测和分析
结合 DTK 做设备资源管理和任务调度

10.5 个人理解：那么gstreamer其实就是一个pipeline架构编写的工程代码，然后内部是可以处理从视频解码--处理--视频编码的这样一个流程的，然后里面包含很多个element，我可以这么理解吗，

10.6 疑问：如果在国产cpu上，我们是不是可以把硬件编解码封装成一个插件然后加载到gstreamer上面，对吧

是的，你理解完全正确。

在国产 CPU 或国产平台上，如果有硬件编解码能力（比如通过某个媒体加速器、专用硬件模块或异构加速卡来做 H.264/H.265 编码解码），我们完全可以把这个能力封装成 GStreamer 插件，然后在 GStreamer 管道中调用它，

10.7 编写插件的疑问

我的理解是我写的插件肯定是要完成下面的差不多的工作实现gstream框架要求的一些虚函数的具体实现还要register我的插件，我觉得这些应该是必不可少的，那么为什么我编写的插件编译成.so之后直接放到gstream本来的安装目录下就行了，那我这个插件是怎么和gstreamer衔接起来的，我的理解这个类似register函数不应该是要在gstream主体中调用的吗，

你提的问题非常关键，说明你对插件加载机制有深入思考了。

虽然你没有修改 GStreamer 主体代码，但 GStreamer 在启动时会自动扫描插件目录，动态加载 .so 文件，然后通过你在插件中定义的 GST_PLUGIN_DEFINE(...) 宏自动完成插件注册。

10.7.1 插件以 `.so` 形式放入 GStreamer 插件搜索路径（比如 `/usr/lib/gstreamer-1.0/`）

GStreamer 在运行 gst-launch-1.0 或加载库时，会扫描该路径下的所有 .so 文件，尝试动态加载。这通过 g_module_open()（glib 里的跨平台 dlopen）来实现。

10.7.2 每个插件 `.so` 中都必须包含一个宏

GST_PLUGIN_DEFINE (GST_VERSION_MAJOR,GST_VERSION_MINOR,yourpluginname,"description...",plugin_init,  // 插件初始化函数VERSION,"License","Package","URL"
)

这个宏做了三件事（重点来了）：

它定义了一个特殊的函数（并使用了 constructor 属性）：

__attribute__((constructor))
static void _gst_plugin_static_init (void) {gst_plugin_register_static(...);
}

这个函数会在 .so 被加载时自动调用，完成注册！

所以，你的 .so 被 dlopen() 时，这个注册代码就会运行，自动把插件注册到 GStreamer 的插件注册表中。

10.7.3 GStreamer 内部会调用你提供的 `plugin_init()` 函数

你在 GST_PLUGIN_DEFINE(...) 宏里传入的 plugin_init 函数，会在 .so 被加载后由 GStreamer 自动调用，用于注册你自己实现的 element，例如：

gboolean plugin_init (GstPlugin *plugin) {return gst_element_register(plugin, "yourhwdec", GST_RANK_PRIMARY, GST_TYPE_YOUR_HWDEC);
}

11 DeepStream

11.1 什么是 DeepStream？

DeepStream 是 NVIDIA 推出的一款基于 GPU 的多媒体分析与推理框架，主要用于构建端到端的视频分析解决方案。它整合了视频解码、预处理、深度学习推理、后处理和显示/输出的能力，支持高效处理视频流。

目标场景：智慧城市、智能交通、零售分析、安防监控等需要实时视频分析的应用。
架构基于 GStreamer，利用硬件加速解码器和 TensorRT 优化推理，性能极高。
支持多视频流并行处理，适合多摄像头场景。

11.2 DeepStream 的核心特点

11.3 疑问：deepstream是英伟达根据gstream架构模仿的，还是说直接就是在gstreamer代码的基础上直接修改的

DeepStream 不是“模仿” GStreamer 架构，而是 直接基于 GStreamer 框架开发的扩展系统，底层完全复用了原生 GStreamer 的代码库和机制。
也就是说，它是“站在 GStreamer 上，增加了 NVIDIA 自家的插件和封装逻辑”，而不是重写或仿写。

DeepStream 和 GStreamer 的关系是“插件 + 封装”，而不是“魔改”：

GStreamer 本身是一个插件化的多媒体框架，允许外部开发者写自己的插件，按标准注册，自动加载。
NVIDIA 写了一堆自己的插件（比如 nvinfer, nvstreammux, nvtracker, nvdsosd 等），这些插件就是标准 GStreamer 插件，只不过它们的实现内部用了 CUDA、TensorRT、NvBuf 等硬件加速库。
这些插件和 GStreamer 主体是解耦的：你安装 DeepStream SDK 的时候，GStreamer 本体是用系统默认的，插件是单独安装的 .so 文件。

也就是说：

DeepStream = GStreamer（官方开源库） + NVIDIA 自研插件（闭源）+ 示例程序 + 配置系统。

11.4 个人理解

解码、推理等，NVIDIA 插件用的是自家的加速技术，DeepStream 的核心价值点就在这里：

功能	插件名	技术细节
解码	`nvv4l2decoder`, `nvjpegdec` 等	使用 NVDEC/NVJPEG 等 GPU 硬件加速解码模块
推理	`nvinfer`	内部使用 TensorRT 进行推理，支持 batch + FP16/INT8 加速
后处理	`nvtracker`, `nvosd`	包括基于 GPU 的绘图（OpenGL）、跟踪算法（KLT/IOU）等
多路合流	`nvstreammux`	将多视频流合并为一个 batch tensor，充分利用 TensorRT 的并行性
输出	`nvmsgbroker`, `nvmsgconv`	与 Kafka/MQTT/数据库交互，适配边缘计算场景