高通跃龙IQ-9100平台的极限压力测试(1): 测试方案设计与多路4K视频解码压测

1. 前言

1.1 实验室环境与业务承载环境的差异

在BSP开发实践中，实验室环境下演示流畅而实际产线中出现性能问题的情况较为常见。产线环境中，四路枪机同时推送4K HEVC码流、质检模型并行运行、风扇积灰、机柜温度升高、市电波动等因素，在实验室测试中通常未被充分模拟。极限压力测试的目的并非提升测试分数，而是在真实工业场景中常见的负载叠加条件下，提前评估平台的实际性能上限及失效前的征兆。

高通跃龙IQ-9100平台的解码、显示、推理、网络、存储等模块通常共享内存带宽和热预算。针对客户关于“最多支持几路4K解码”的询问，仅依据编解码器规格书提供的理论值作答可能导致后续问题。因此，该测试方案首先对多路硬件解码进行独立压力测试，以明确解码子系统的性能边界，后续再叠加AI推理负载——后者将在第二部分讨论。

1.2 本文范围

本文仅涉及以下内容：测试方案设计、环境搭建、多路4K HEVC解码加压方法、解码性能上限判定、温度与降频观测。不重复已发布过的Greengrass、Ride、Redroid、QIRP、bootloader工具链等内容；在压力测试阶段，刻意关闭推理模块以避免变量干扰。

2. 测试方案设计

极限压力测试方案矩阵图：

2.1 测试矩阵定义

采用三维测试矩阵：

• 路数轴：1路、2路、4路为主线；若有余量，增加6路、8路探顶。步进必须清晰，避免直接跳至最大路数导致问题定位困难。
• 分辨率轴：以 3840×2160 为主战场；对照测试包括 2688×1520 和 1080p，用于区分瓶颈是像素率还是解码实例个数。
• 编码格式轴：主测HEVC（H.265）；以AVC（H.264）作为基线，比较同路数下CPU参与程度的差异。所有测试样片采用固定GOP、固定码率或CRF档，文件名中包含参数说明。

测试矩阵应打印并记录，任何条件变更需签字确认。

2.2 测试工具：GStreamer与FFmpeg双轨验证

• GStreamer：用于硬件解码插件链路测试，便于分析丢帧、缓冲及队列长度。典型管道为：filesrc或udpsrc输入，经h265parse连接硬件解码器，再通过fpsdisplayink或fakesink剥离显示开销。具体解码元素名称依BSP发布说明而定。
• FFmpeg：用于交叉验证。同一片源使用-hwaccel参数走硬件路径，与GStreamer结果对比。若两者帧率差异显著，表明存在额外拷贝或色彩空间转换，需进一步分析。

两套工具同时保留，用于单工具异常时的相互验证。

2.3 监控指标集

监控指标收敛为以下内容：

• 实时帧率与目标帧率偏差：每路单独记录，汇总最小值，关注最慢一路。
• 丢帧计数/丢帧率：通过工具自带统计或在sink前插入probe统计buffer时间戳跳变。
• 端到端延迟：必要时在片源中嵌入时间戳水印，通过屏摄或录屏比对。解码链路单独测试时不强求，叠加推理时再测量。
• CPU占用、GPU占用（若平台支持）、整机功耗：同一采样周期写入CSV，与温度曲线对齐。
• DDR带宽或总线繁忙度：若BSP暴露计数器，固定采样脚本获取；否则通过memcpy类基准测试作为旁证。
• 热区温度与CPU/NPU频率：重点关注热节流(throttling)。采样间隔设为1秒，长时间运行降至5秒以节省存储。

3. 测试环境搭建

3.1 硬件配置的可复现性要求

开发板固定支架，网线选用经过验证的稳定品牌，存储采用同一块NVMe或同速U盘，避免存储成为解码瓶颈。内存容量（如16GB与8GB）必须记录在测试报告首页。

3.2 散热方案记录

至少测试两种工况：开放对流（桌面风扇直吹）与模拟风道受阻（部分遮挡进风口或降低风扇转速）。散热条件必须写入报告，否则测试数据无效。

3.3 供电监控

使用智能插座或USB功耗表采集功耗数据，观察加压后功耗阶跃变化。若功耗在某路数档位不再上升而帧率持续下降，表明瓶颈已从算力转移到带宽或调度。采样与性能日志采用同一时间基准。

3.4 温控传感器部署

除板载热敏电阻外，在SoC表面或散热片边缘粘贴K型热电偶，记录仪每10秒记录一个点。比较板载thermal zone与外部测温的差异：差值在 2℃ 以内视为正常，超过 5℃ 需检查导热垫或螺丝扭矩。部署位置拍照存档，便于复现。

4. 多路4K HEVC解码压测

4.1 加压节奏

测试流程固定：单路先跑满30分钟，确认FPS贴近片源帧率且丢帧计数为零。然后增加第二路，两路片源启动时间错开数秒，避免启动风暴。第三、第四路同理。每档至少稳定运行15分钟再进入下一档。

记录时同时运行解码进程和采样进程。GStreamer管道示例（具体解码元素依平台替换）：

gst-launch-1.0-v\multifilesrclocation="test4k_%02d.hevc"loop=true\!h265parse!<hw_decoder_element>!fakesinksync=true

多路解码时启动多个shell或脚本循环，每路输出重定向至独立日志。

4.2 CPU/GPU曲线采样

使用简单的采样循环，若无tegrastats则用top或mpstat，间隔1秒追加至文件：

whiletrue;dodate+%sgrep-E'^(cpu|Mem)'/proc/statsleep1done>>decode_load.log

GPU节点若存在（如/sys/class/kgsl/kgsl-3d0/gpu_busy_percentage），一并读取。将路数作为额外列写入同一CSV，绘图时以背景色区分不同路数阶段。

4.3 丢帧率统计

每路维护 frames_dropped / frames_total。若工具未提供，则自行计数。丢帧率从千分之几跳变至百分之几的档位定义为警戒档。重点关注最差一路的丢帧表现。

曾遇到一种现象：总帧数对账无误，但某路画面出现间隔性重复帧。通过GST_DEBUG=*:2及在identity元素上打时间戳，定位为队列偶发积压而非硬件解码失败。因此，每路额外记录最大帧间隔：

连续两帧间隔超过2 × (1000 / fps_target)ms即记一次异常，与丢帧并列。

4.4 FFmpeg交叉验证命令

同一片源避免修改容器，以免demux干扰。常用命令：

ffmpeg-hwaccel<name>-hwaccel_output_format<fmt>-iinput_4k30_hevc.mp4\-fnull --benchmark

多路时启动多个进程绑定不同输入文件。截取benchmark输出的fps与GStreamer中fpsdisplayink的打印结果进行同期比较。差值在 5% 以内视为通过；超出则检查是否存在软解或隐式格式转换（如NV12→RGB）。

5. 解码器资源上限探索：瓶颈定位

5.1 上限判定条件

以下三个信号同时出现时判定为达到硬顶：

• 再增加一路，所有路的FPS同步下降（非单路掉队），表明总资源池耗尽。
• 功耗或带宽计数器触顶，而CPU占用不高。
• dmesg出现alloc失败或驱动retry，表明进入不可靠区域，该路数记录为硬顶，不推荐用于产品配置。

5.2 实例数瓶颈与带宽瓶颈的区分实验

• 实验A：路数不变，将分辨率从4K降至1080p。若FPS立刻全线回升，说明对像素处理量敏感，瓶颈偏向解码或带宽。
• 实验B：分辨率不变，增加路数。若硬件计数器显示解码session已满而带宽仍有余量，瓶颈偏向实例数或固件限制。

5.3 内存带宽测证方法

在解码压力测试的同时，另开终端运行可控带宽的内存搬运工具（或dd if=/dev/zero of=/dev/null配合taskset绑定CPU核心），观察解码FPS是否进一步下滑。若轻微后台搬运即导致多路抖动，说明DDR带宽已接近极限，此时应降低码率或改用子码流策略。若后台搬运不影响解码而路数无法增加，则重点检查会话上限及驱动返回值。

6. 温度与降频观测

6.1 温升与路数的关系

温升与路数并非线性关系。1路时壳温较低，4路时热点可能突跳至门限附近，原因在于DDR和显示相关时钟的负载增加。每个路数档位结束时记录一张热分布图，并标注环境温度。

6.2 降频触发点定位

周期性读取CPUfreq当前频率及thermal throttle状态（节点路径因平台而异，在报告附录中提供find /sys -name throttle*的结果截图）。首次出现持续降频的路数定义为“热约束下的有效路数”，通常比纯解码天花板低1~2路。该数据在投标时应明确告知销售与售前人员。

6.3 温度曲线与丢帧的联合分析

将thermal.log与drop_rate.csv按时间戳合并，使用gnuplot或Excel绘制双纵轴图。典型形态为：温度触顶后5~10秒，丢帧率开始上升——这种滞后必须在报告中说明，避免现场工程师误判为解码器突发故障。若丢帧先于温度上升，则需检查片源码率尖峰或磁盘read stall。

7. 小结：多路解码能力汇总表

以下汇总表用于项目组评审：

备注栏包含：片源CRF/码率、GStreamer版本、内核commit。评审时仅投影此表即可。

多路4K解码独立压测完成后，后续将在同一监控口径下叠加YOLOv8推理，评估帧率、延迟变化及系统在长跑和故障注入下的自恢复能力。