3. 工业图形软件栈全景
在 Ryzen Embedded 平台上做工业图形工程，最先要建立的认知是：图形不是单一软件，而是一条从内核到应用的多层栈。同一块 Radeon 图形核心，在 Linux 下可能走 DRM/KMS + Mesa RADV，也可能走 AMDGPU-PRO 专有栈；在 Windows 下走 WDDM 驱动模型；而计算任务则可能绕开图形管线，直接走 ROCm/OpenCL。选错一层，轻则性能打折，重则功能不可用。本节把这条栈拆开，说明每层的职责、接口和嵌入式场景下的适用边界。
一、Linux 显示与渲染通路：DRM/KMS 是地基
Linux 下所有图形输出的根都在 DRM（Direct Rendering Manager）与 KMS（Kernel Mode Setting）。DRM 负责显存管理、命令提交和 GPU 调度，KMS 负责显示控制器、CRTC、连接器（Connector）与显示模式设置。工业设备常见的“无桌面、直接出图”场景，正是通过 KMS 的 dumb buffer 或 GBM（Generic Buffer Management）分配缓冲，再经 Atomic Modesetting 提交到扫描输出。
一个典型的嵌入式直显路径是：应用通过 libdrm 打开 /dev/dri/card0，用 drmModeGetResources 枚举 CRTC 与连接器，创建 dumb buffer 并映射，绘制后调用 drmModeAtomicCommit 提交。这条路径不依赖 X11/Wayland，启动快、内存占用低，适合 HMI 面板、机器视觉取像显示等固定分辨率场景。需要注意：KMS 只管“把缓冲送到屏幕”，不管 3D 渲染，渲染要交给 Mesa 或专有驱动。
二、Mesa RADV 与 AMDGPU-PRO：两条用户态路线
用户态图形驱动在 Linux 上主要有两条路线。第一条是开源 Mesa 栈：内核用 amdgpu 模块，用户态用 RADV（Vulkan）和 RadeonSI（OpenGL）。RADV 是社区维护的 Vulkan 实现，更新快、与上游内核同步好，适合需要长期维护、可审计的工业产品。第二条是 AMDGPU-PRO 专有栈，提供经过认证的 Vulkan/OpenGL 驱动，通常在特定 LTS 内核和发行版上做兼容性验证，适合对认证、长期支持有要求的场景。
两者的关键差异不在“能不能跑”，而在版本耦合与可维护性。RADV 随 Mesa 版本演进，遇到问题可以查上游、提 patch；AMDGPU-PRO 则依赖 AMD 的发布节奏，内核、固件、用户态驱动需要成套匹配。工业项目生命周期常达 5～10 年，若选择专有栈，必须锁定整套版本并保留离线安装包；若选择 Mesa，则要评估发行版升级带来的回归风险。
三、Windows 驱动模型：WDDM 的约束
Windows 下图形栈由 WDDM（Windows Display Driver Model）统一管理。AMD 为 Ryzen Embedded 提供对应的 Windows 显卡驱动，应用通过 DXGI/D3D 或 Vulkan 访问 GPU。WDDM 的优势是驱动模型成熟、多显示器与电源管理完善；约束是显示模式切换、独占全屏、低延迟直显等行为受系统调度影响，不如 Linux KMS 那样可直接控制扫描输出时序。对于需要硬实时同步的工业相机显示，Windows 路线通常要借助厂商 SDK 或专用采集卡来补偿。
四、ROCm/OpenCL 与图形 API 的分工
计算与图形是两条并行的栈。ROCm 提供 HIP 编程模型和运行时，OpenCL 则更轻量、跨厂商。工业场景中，图像预处理（去噪、畸变校正、直方图）、推理前处理、点云滤波等适合放到计算栈；而界面合成、3D 可视化、视频显示走 Vulkan/OpenGL ES。判断依据很简单：如果任务是“逐像素或逐元素并行、结果写回内存”，优先计算栈；如果任务涉及图元装配、光栅化、纹理采样和显示合成，走图形 API。
Vulkan 与 OpenGL ES 的选择也有工程含义。Vulkan 显式管理命令缓冲、内存和同步，CPU 开销低、多线程友好，适合复杂 HMI 和高帧率场景；OpenGL ES 上手快、代码量小，适合功能固定的简单界面。嵌入式 GPU 资源有限时，Vulkan 的显式控制反而能避免驱动隐式分配带来的内存峰值。
五、嵌入式场景的适用性对比与选型建议
把上述分层落到具体项目，可以用几个维度快速判断。第一是显示控制粒度：需要精确控制扫描输出、无桌面直显，选 Linux DRM/KMS；需要成熟多屏与电源管理，选 Windows WDDM。第二是维护周期：5 年以上且团队有能力跟进上游，选 Mesa RADV；需要厂商认证与固定版本，选 AMDGPU-PRO 并锁定整套固件与内核。第三是任务类型：图形合成与 3D 走 Vulkan/OpenGL ES，逐像素并行计算走 ROCm/OpenCL。第四是实时性：对延迟敏感时，Vulkan 的显式同步比 OpenGL ES 更可控。
一个常见的工业 HMI 组合是：Linux + amdgpu + Mesa RADV + Vulkan，配合 KMS 直显；图像预处理用 OpenCL 或 HIP 在独立队列上执行，通过共享缓冲与图形队列同步。若产品需要 Windows 生态，则改为 WDDM 驱动 + D3D/Vulkan，计算部分用 OpenCL 或 DirectML。两条路线在应用层可以共用大部分业务代码，但驱动与同步模型必须分别验证。
六、验证与观察要点
栈是否选对，最终要靠可观察的证据。Linux 下可用 drm_info 查看 KMS 资源与 Atomic 能力，用 vulkaninfo 确认 RADV 或 AMDGPU-PRO 的驱动版本与队列族，用 clinfo 查看 OpenCL 平台与设备。Windows 下用 DXDIAG 查看 WDDM 版本与驱动日期。工业现场还应记录：直显路径的首帧延迟、计算队列与图形队列的同步开销、长时间运行下的显存占用曲线。这些数据比“能跑起来”更能说明栈是否适合量产。
需要强调的是，本节给出的参数与组合属于工程示例与合理假设，实际项目应以目标板卡的 BSP、内核版本和厂商发布说明为准。不同 Ryzen Embedded 型号的图形核心代际不同，对 Vulkan 扩展、ROCm 支持矩阵和固件版本的要求也不同，选型前务必核对官方支持列表。