[参考译文] AM62A7：TIDSS 错误

恢复固件和 tild 库后、此 tidss 错误不再出现。

尊敬的 Jason：

这是一个有趣的观察。 TIDSS 不应与 TIDL 元件直接相关、但我知道为什么会这样。  

TIDL 10.1 版本对性能敏感型元件进行了一些更改、现在某些型号的性能有所不同。 那么、为什么这很重要呢？

您接收到的 tidss 消息通常意味着 gstreamer 管道和监视器之间的同步丢失、可能是因为某些帧被丢弃。 如果您的模型运行速度低于显示器输出速度、则可能会发生这种情况。  

我相信如果您将 kmssink 插件上的'sync'设置设置设置为 false、此问题应该会解决。 我使用的大多数 gstreamer 流水线的最后一个插件类似于以下：  

kmssink driver-name=tidss force-modesetting=true sync=false

您没有具体提到您使用 gstreamer、但我假设是这样。 如果这是错误的假设、请进行更正。  

嗨、Reese

正如您所说、我使用 GStreamer 进行视频输出。 当算法以 25fps 至 30fps 的速率运行时、我的输出帧速率为 60fps。 虽然我设置了sync=false kmssink,但我没有启用force-modesetting=true。

    kmssink->set_property("sync", FALSE);
    kmssink->set_property("can-scale", FALSE);
    kmssink->set_property("skip-vsync", TRUE); // 60 fps

BR

Jason

嗨、Reese

我忘记提及我也更新了libtivision_apps.so库。这也包括在tidl_lib.tar.gz包中。

BR

Jason

尊敬的 Jason：

强制模式设置参数对将监视器分辨率设置为与来自 gstreamer 的流相同的输出分辨率具有更大的影响。 如果您已设置 sync=false、则可能不会改变您这边的行为。 显示器是否仍然闪烁？

我似乎记得关于同一主题的内部对话----让我问几个发展人员是否有不同的解决办法（假设问题仍然存在）。

在 kmssink 之前插入队列是否会改变任何行为？

编辑:我发现一个外部发布的 JIRA 与这个问题相关。 对于默认情况下运行的演示应用、我们交换了具有较低分辨率/延迟的模型、因此可以规避这些问题。 我会看看我们是否可以提供任何其他建议

BR、
Reese

嗨、Reese

我遇到的问题是在为 kmssink 设置 sync=false 时发生的、并且 kmssink 之前已经存在队列。 完整的流水线如下所示：

cam -> msc -> caps -> q -> mosaic -> q -> kmssink
       |
       +----> caps -> q -> msc2 -> caps -> q -> appsink(algo)

BR

Jason

尊敬的 Jason：

我一直在与我们的开发团队讨论这个问题。 无论是针对您的 SDK 版本还是更新的 11.1、此显示耗尽问题都没有全新的修复。 主要权变措施是避免以低于 30fps 的速率运行显示流水线

这种闪烁问题可以通过运行更小/更快的模型来解决、这样 KMSSINK 插件就不存在限制性能< 30fps 的瓶颈。 如果 tiovxmosaic 和 kmssink 插件之间有 tiperfoverlay 插件、您还可以尝试删除类似 tiperfoverlay 插件的任何内容。

30 fps  显示器是否是 您的关键要求的一部分？ 我们在该器件上包含一个显示子系统、但由于没有 GPU、因此其实用程序更有限。 此 DSS 组件通常用于调试和开发、但在生产系统中不太常见。 一种更常见的用例是使用视频编码器创建输出视频

另一种选择是使用应用代码、这样它会强制输出图像以 30FPS 速率可用、即使这意味着重新播放旧帧（以及识别何时应跳过推理以保持 FPS）也是如此。  

BR、
Reese

嗨、Reese

我们的应用是摄像头后视镜系统、需要开发符合 R46 和 ISO 26262 (ASIL-B) 标准的产品。 因此、显示组件至关重要。 为了实现更好的视觉性能和更低的显示延迟、我们当前的摄像头以 60fps 运行、分辨率为 1920x720、因此视频流也以 60fps 运行。

关于您提到的“更小/更快的模型“、应该从哪些尺寸进行评估？ 它是基于模型输入大小吗？ 网络规模？

BR、

Jason

尊敬的 Jason：

了解系统要求。 是的、这需要全速率而不会闪烁。 您还可以考虑使用 TIDL 与输出视频流异步运行 AI 模型。 使用 gstreamer 时、这将需要 appsrc/appsink 和相应的应用代码

关于您提到的“更小/更快的模型“、应该从其尺寸进行评估

从根本上说、这是延迟驱动的。 如果此模型与您的成像/视频管道同步运行,您需要更快的运行时间。

减少输入尺寸是实现此目的的一种方法（对于许多 CNN，无需再培训）。 否则、您可以减少层的大小（例如卷积的通道数）及其数量（即深度学习模型的深度）  。  

请记住、运行更小/更快的模型通常会导致一定的精度损失。

在我之前提到的外部 Jira 票证[1]中,我们用较小的分割模型替换了 deeplabv3 模型。 这是一个更简单的模型,并且具有更小的尺寸 (512->384)。  

BR、
Reese

嗨、Reese

谢谢你。 我将与我们的算法同事协调、在未来几天尝试这种方法、并将报告结果。

BR、

Jason

好的、感谢您的快速确认、Jason。

如果您想将任何 appsrc / appsink 使用情况的引用作为异步处理的起点（如果您选择沿该方向执行）、请告诉我。  

嗨、Reese

我已经使用 appsink 实现了异步处理。 下面是我的主要媒体流水线节点的连接图:在 MSC_1 中,我获得了一个 608x352 图像帧,该帧被传送到 appsink,然后一个专用线程从接收器检索该帧,并将其馈送到算法中进行处理。

BR

Jason

哦、原谅我的误解。 尽管 已经 在 appsink/async 线程中运行了 AI 算法、但您仍然遇到显示不足的问题。

对于多分频器和马赛克、您是否为这些设置了目标属性？ MSC 有 2 个物理实例（目标 0 和 1）。 这些马赛克和多标量插件都使用这些 MSC。 另外,马赛克插件的两个源是什么? 它只是一个馈送、但添加了覆盖/背景图像吗？

我也很好奇、您是否使用了任何 gstreamer 功能（包括我们的 GST-tracers 工具[1]）来确定本例中的帧丢弃位置。 用于算法的 Appsink 当然将使用 DDR、但除此之外、该流水线应该能够跟上 60FPS、即使对于来自摄像头的较大输入帧（例如 5MP）也是如此

• 如果您移除 appsink 和相应的处理、我想您看到的是预期的平滑 60 FPS？ 请确认。  

[1] https://texasinstruments.github.io/processor-sdk-doc/processor-sdk-edgeai-AM62AX/esd/docs/11_01_07_05/edgeai/measure_perf.html#parse-gst-tracers 

BR、
Reese

嗨、Reese

我为 2 个 MSC (0 & 1) 设置了不同的目标。

在我们的应用中、屏幕分辨率为 1920x720、摄像机分辨率为 1920x1536@60。 为了满足 R46 II 和 IV 级的视野要求。我们通过 MSC 将单个摄像机帧拆分为两个：一个符合 II 级标准、另一个符合 IV 级标准。

对于 chn0、屏幕上的显示区域从大小为 1280x720 像素的坐标 (0、0) 开始、而 chn1 从大小为 640x720 像素的 (1280、0) 开始。 因此、我们需要使用马赛克处理将这两个通道合并为单个 1920x720 显示输出。

在以前的测试中、我明显地观察到、当系统输出日志消息“tidss 30200000.dss: CRTC1 sync lost：(IRQ 800)“时、帧不停地抖动。 因此、我故意避免使用示踪剂工具进行诊断。

我将验证删除 appsink（即，禁用算法处理）是否可以保持 60 FPS 性能、并将在此时间范围内为您提供更新。

BR

Jason

嗨、Reese

删除 appsink 分支后、tidss 中没有错误日志。

BR

Jason

尊敬的 Jason：  

这是一个有趣的发现。 现在、我很好奇这个问题是与运行 TIDL 的 C7xMMA 有关、还是与 DDR 上的高负载有关（A53 也可能相关）。

您可以使用 stress-ng 命令模拟 DDR 负载、如所示  

stress-ng --memrate 1 --memrate-wr 2000 --memrate-rd 2000 -v

如果您在应用程序期间在后台运行此消息、您是否会看到类似的同步丢失消息、即使 appsrc 不存在也是如此？ 我无法重现此同步丢失问题的类似行为


我还有另一个问题 — 您在执行此操作时，Weston 或 Wayland 窗口管理软件是否正在运行？ 您可以使用“systemctl"检查“检查该服务是否存在于所示的交互式日志记录中。  

嗨、Reese

这是我们应用的完整流水线。 共有两个来源：一个是摄像头 (cam)、另一个是 videotestsrc、当未连接摄像头时、它会输出黑屏以显示。 此外、还有四个接收器：一个是用于实时显示的 kmssink、另三个对应于不同的功能模块。 其中、appsink_alg 用于算法处理、appsink_detect 使用 OpenCV 执行图像质量检测、而 appsink_venc 用于视频录制。 经过几轮验证后、我发现当同时启用所有三个功能模块时、会发生与 DSS 相关的错误以及屏幕撕裂。 但是、如果仅启用三个模块 (ALG、Detect、VENC) 中的任何一个、则不会出现屏幕撕裂。 在我们升级 TIDL 版本之前、同时运行所有三个功能模块一直都可以正常工作。 因此、我继续验证了您提到的 DDR 使用问题。 stress-ng --memrate 1 --memrate-wr 2000 --memrate-rd 2000 -v在后台运行并仅启用实时显示（即全部三个功能模块均被禁用）时、不会发生屏幕撕裂。

此外、由于我们img是从最小文件系统扩展而来的、因此文件系统中不包含 Weston 和 Wayland 等组件、因此这些进程也不会在后台运行。

BR

Jason

尊敬的 Jason：

这里的综合视图非常有用、值得赞赏。 也感谢您运行这些测试。  

因此、我继续验证了您提到的 DDR 使用问题。 stress-ng --memrate 1 --memrate-wr 2000 --memrate-rd 2000 -v在后台运行并仅启用实时显示（即禁用所有三个功能模块）时、不会发生屏幕撕裂。

因此您说、当只有 2 个此类应用受电方处于活动状态时、流水线行为良好、而当您添加第三个应用时、无论哪一个应用会失败。 您是否可以与这 2/3 个受电方同时运行此应力测试？ 您还可使用与以下相同的工具来模拟 CPU (A53) 负载：  

stress-ng --cpus <ncpus> --cpu-load <percentage as int like 40> --timeout <duration_in_seconds>

• 我已经从性能指标（DDR、CPU 负载）中注意到、该行为是突发的、可能会在短时间间隔内超过设置的百分比。   如果是资源争用、这将使错误更容易重现。  
• 如果您以与映像流水线不同的速率运行 TIDL、DDR 利用率肯定会非常高

我要确定的是、此同步丢失效应是否是系统 DDR 负载/CPU 负载所致。 libtivision_apps 将通过 TIDL 库依赖的 TI OpenVX 触摸 gstreamer 插件的底层实现。 C7x 固件本身应仅影响 C7x 行为和系统 DDR 负载。 除非该问题与系统级性能有关、否则我不确定这些库会如何导致屏幕撕裂

dmesg/内核日志是否显示来自 VPU 又名 wave5 视频编码器/解码器的消息？ 如果您可以共享 dmesg 日志、这也可能会提供信息

我还想知道您的应用与最大 DDR 分配的接近程度如何。 如果您接近此分配、我可以看到队列中的缓冲区正在尝试分配、但无法及时丢弃帧的情况。 是否修改 tiovx*插件的任何缓冲池大小？

此外、我假设（但您可以验证是否愿意）gstreamer 将识别被丢弃的帧。 您是否分析过这些情况可能发生在哪里？ KMSSink 是显而易见的,但它可能也发生在其他地方。 [1]

[1] https://software-dl.ti.com/processor-sdk-linux/esd/AM62AX/11_01_07_05/exports/docs/edgeai/measure_perf.html#parse-gst-tracers

BR 感谢您的耐心——这是一个具有挑战性的问题
Reese

嗨、Reese

请允许我用新的调查结果更新我先前的发言。

如果三个模块 (ALG、Detect、venc) 中只有任意两个启用、则不会发生屏幕撕裂

在现实中,我的测试显示了这一点 ​当appsink_algo 与一个或多个附加功能模块一起启用时、屏幕撕裂以及“CRTC1 SYNC LOST“错误都会发生 。 例如：

• 智能 algo + detect

• 智能 algo + venc

• 启用所有三个algo + venc + detect ()

不过、 ​如果仅detectvenc启用和（不启用）algo、则不会出现问题 。

此外,我测试运行stress-ng以模拟内存压力,同时使用已确认的有问题的管道配置。 结果表明了这一点 ​在 DDR 应力下、屏幕撕裂的频率没有显著增加 。

root@am62axx-evm:~# stress-ng --memrate 1 --memrate-wr 2000 --memrate-rd 2000 -v
stress-ng: debug: [1220] invoked with 'stress-ng --memrate 1 --memrate-wr 2000 --memrate-rd 2000 -v' by user 0 'root'
stress-ng: debug: [1220] stress-ng 0.17.05 g4e68895f4fe6
stress-ng: debug: [1220] system: Linux am62axx-evm 6.6.32 #46 SMP PREEMPT Wed Oct 22 09:41:51 HKT 2025 aarch64, gcc 13.3.0, glibc 2.39
stress-ng: debug: [1220] RAM total: 3.2G, RAM free: 2.8G, swap free: 0.0
stress-ng: debug: [1220] temporary file path: '/root', filesystem type: ext2 (26415103 blocks available)
stress-ng: debug: [1220] 4 processors online, 4 processors configured
stress-ng: info:  [1220] defaulting to a 1 day, 0 secs run per stressor
stress-ng: debug: [1220] cache allocate: using cache maximum level L2
stress-ng: debug: [1220] CPU data cache: L1: 32K, L2: 512K
stress-ng: debug: [1220] cache allocate: shared cache buffer size: 512K
stress-ng: info:  [1220] dispatching hogs: 1 memrate
stress-ng: debug: [1220] starting stressors
stress-ng: debug: [1220] 1 stressor started
stress-ng: debug: [1221] memrate: [1221] started (instance 0 on CPU 1)
stress-ng: info:  [1221] memrate: using buffer size of 262144K, cache flushing disabled
stress-ng: info:  [1221] memrate: cache flushing can be enabled with --memrate-flush option

以下是 CRTS1 同步丢失错误后的 dmesg 日志
e2e.ti.com/.../error_5F00_dmesg.log

这是顶部输出和顶部输出

// HERE IS THE TOP OUTPUT
op - 01:27:29 up 5 min,  2 users,  load average: 2.10, 1.57, 0.75
Tasks: 151 total,   1 running, 150 sleeping,   0 stopped,   0 zombie
%Cpu(s): 40.1 us,  8.5 sy,  0.0 ni, 48.2 id,  0.0 wa,  2.5 hi,  0.8 si,  0.0 st
MiB Mem :   3319.5 total,   2867.5 free,    378.9 used,    220.1 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   2940.6 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   1094 root      20   0 1730968 102960  25336 S 189.4   3.0   0:49.19 media_main
    406 root     -51   0       0      0      0 S   2.3   0.0   0:03.37 irq/15-mbox-r5-0
    383 root      20   0       0      0      0 S   1.0   0.0   0:01.23 vpu_irq_thread
   1127 root      20   0    7436   4480   2432 R   1.0   0.1   0:00.17 top
   
// HERE IS THE HTOP OUTPUT

    0[###################################**********************                                  58.1%] Tasks: 37, 54 thr, 99 kthr; 0 running
    1[########################################**********                                         51.3%] Load average: 3.54 2.42 1.20
    2[###########################################********                                        52.2%] Uptime: 00:07:38
    3[#######################################****************                                    56.3%]
  Mem[|||||||#@$$$$$$                                                                       240M/3.24G]
  Swp[                                                                                           0K/0K]

  [Main] [I/O]
    PID USER       PRI  NI  VIRT   RES   SHR S  CPU%-MEM%   TIME+  Command
   1173 root        20   0 1692M 98.4M 25208 S  42.9  3.0  0:06.95 /root/media_main
   1166 root        20   0 1688M 98.4M 25208 R  37.8  3.0  0:06.27 /root/media_main
   1168 root        20   0 1690M 98.4M 25208 S  33.3  3.0  0:05.46 /root/media_main
   1161 root        20   0 1690M 98.4M 25208 R  20.5  3.0  0:03.31 /root/media_main
   1163 root        20   0 1690M 98.4M 25208 S  10.3  3.0  0:01.65 /root/media_main
   1172 root        20   0 1690M 98.4M 25208 S   9.6  3.0  0:01.55 /root/media_main
   1167 root        20   0 1688M 98.4M 25208 S   9.0  3.0  0:01.60 /root/media_main
   1154 root        20   0 1690M 98.4M 25208 S   7.1  3.0  0:01.22 /root/media_main
   1165 root        20   0 1690M 98.4M 25208 S   5.8  3.0  0:01.05 /root/media_main
   1174 root        20   0 1690M 98.4M 25208 R   5.1  3.0  0:00.72 /root/media_main
   1151 root        20   0 1690M 98.4M 25208 S   3.8  3.0  0:00.65 /root/media_main
   1176 root        20   0  5632  3968  2432 R   3.8  0.1  0:00.59 htop
   1169 root        20   0 1690M 98.4M 25208 S   3.2  3.0  0:00.52 /root/media_main
   1162 root        20   0 1690M 98.4M 25208 S   1.9  3.0  0:00.34 /root/media_main
      1 root        20   0 19044 10572  7628 S   0.0  0.3  0:02.03 /sbin/init

当我试图使用增加 CPU 负载stress-ng时、屏幕撕裂的频率似乎确实增加了。

root@am62axx-evm:~# stress-ng --cpu 4 --cpu-load 50 --timeout 200
stress-ng: info:  [1199] setting to a 3 mins, 20 secs run per stressor
stress-ng: info:  [1199] dispatching hogs: 4 cpu
stress-ng: info:  [1200] cpu: for stable load results, select a specific cpu stress method with --cpu-method other than 'all'
stress-ng: info:  [1201] cpu: for stable load results, select a specific cpu stress method with --cpu-method other than 'all'
stress-ng: info:  [1202] cpu: for stable load results, select a specific cpu stress method with --cpu-method other than 'all'
stress-ng: info:  [1203] cpu: for stable load results, select a specific cpu stress method with --cpu-method other than 'all'
[ 1211.978176] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1214.708312] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1216.592337] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1218.457278] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1219.549533] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1219.657815] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1222.005762] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1224.826556] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1225.277437] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1226.068489] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1229.010577] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1233.397963] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1237.191036] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1237.586709] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1239.383986] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1239.905909] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1244.388372] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1247.917870] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1250.397427] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1251.154941] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1258.820905] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1259.202269] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1262.570151] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1264.364950] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
^C^Cstress-ng: info:  [1199] skipped: 0
stress-ng: info:  [1199] passed: 4: cpu (4)
stress-ng: info:  [1199] failed: 0
stress-ng: info:  [1199] metrics untrustworthy: 0
stress-ng: info:  [1199] successful run completed in 55.53 secs
root@am62axx-evm:~# [ 1283.763220] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1358.403009] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)
[ 1421.702536] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 800)

我怀疑这可能与不完整的更新过程有关。 接下来、我计划直接在 SD 卡上创建完整的 10.1 文件系统来进行验证。 但是、由于在 10.1 SDK 中设置整个映像流水线（例如 MAX96714 驱动程序和设备树）会很耗时、因此我更愿意继续在这个当前的 10.0.0.08 文件系统上进行测试。 是否有任何基准测试可帮助排除我们自己的算法模型等因素？

BR

Jason

尊敬的 Jason：

这些都是很好的发现、尤其是 CPU 负载会产生影响。 我想知道这是否与 IRQ 平衡有关。  

是否有一个进程正在运行'irqbalance'的后台？ 这是一个在多个内核之间拆分中断处理的应用程序、因为它们可能都在同一个内核上运行。 如果您基于很小的 Yocto 映像、则可能此应用程序/服务未运行。  

root@am62axx-evm:/opt/edgeai-gst-apps# ps -ax | grep irqbalance
    456 ?        Ssl    0:01 /usr/sbin/irqbalance --foreground
## May also be an `irqbalanced` service shown in systemctl console

如果未运行、请尝试在单独的进程中以`irqbalance -f`的形式运行、查看应用程序是否仍然遇到相同的问题。  

我们还可以看到更多关于运行`cat /proc/interrupts`中的中断的信息--请在应用程序运行一小段时间之前和之后提供此信息的打印输出。  

运行`irqtop`应用程序以查看任何运行时行为也可能有所帮助。 请同时提供打印输出。  

尊敬的 Jason：

这些都是很好的发现、尤其是 CPU 负载会产生影响。 我想知道这是否与 IRQ 平衡有关。  

是否有一个进程正在运行'irqbalance'的后台？ 这是一个在多个内核之间拆分中断处理的应用程序、因为它们可能都在同一个内核上运行。 如果您基于很小的 Yocto 映像、则可能此应用程序/服务未运行。  

root@am62axx-evm:/opt/edgeai-gst-apps# ps -ax | grep irqbalance
    456 ?        Ssl    0:01 /usr/sbin/irqbalance --foreground
## May also be an `irqbalanced` service shown in systemctl console

如果未运行、请尝试在单独的进程中以`irqbalance -f`的形式运行、查看应用程序是否仍然遇到相同的问题。  

我们还可以看到更多关于运行`cat /proc/interrupts`中的中断的信息--请在应用程序运行一小段时间之前和之后提供此信息的打印输出。  

运行`irqtop`应用程序以查看任何运行时行为也可能有所帮助。 请同时提供打印输出。  

尊敬的 Jason：

好吧、irqbalance 已经在运行.. 那么、这不是一个简单的权变措施。 我认为 IRQ 平衡不会影响所有中断、而只会影响某些中断。 TI 特定的 MBOX-c7x-0 等器件仍会固定到内核 0。 尽管如此、我仍然看到您的整个内核 CPU 利用率远低于 80%、因此我预计不会有太多争用、导致经常错过中断或信号期限。

您可以尝试将一些 IRQ（主要是 mobx-c7x-0 和 tidss）从/proc/irq/N/smp_affinity 固定为 2（或任何其他十六进制值 2 至 D、使位 0 不为 1）。

• “N"是“是 IRQ 编号、显示自/proc/interrupts. 540 对应于打印输出中的滴定
• 在此期间可能需要关闭 irqbalance

我怀疑这可能与不完整的更新过程有关。

如果您在 edgeai-tidl-tools 中运行更新脚本、则迁移过程应该完成。 这将取代 C7x 固件和/usr/lib.下的几个库 这些函数主要用于 TIDL 组件和 libtivision_apps（其中包含 TI OpenVX 函数；对于堆栈的许多部分来说至关重要）。  

• 这是一个范围、但我很好奇 libtivision_apps 是否可以保留为 10.0 原始版本、只会将其他 TIDL 库更新到 10.1。 tivision_apps 通常是更稳定的发布到发布版本。 我会将其视为一个实验、而不是推荐的权变措施。  

我们可能尝试降低 CPU 利用率、但我认为这是错误的做法。 可能值得查看 SDK 10.1。

也许您可以尝试使用编码的视频文件代替实际的摄像头传感器驱动程序来简化此实验。 这会从流水线中删除一些插件（如 tiovxisp）并添加视频解码、因此不是完美的 1：1 比较、但可能足够接近验证在添加 3 个应用接收器时是否也会出现此问题。

嗨、Reese

root@am62axx-evm:~# cat /proc/interrupts | grep tidss
540:        303          0          0          0     GICv3 116 Level     tidss
root@am62axx-evm:~# cat /proc/interrupts | grep mbox-c7x-0
 16:          6          0          0          0     GICv3 109 Level     mbox-c7x-0
root@am62axx-evm:~# echo 2 > /proc/irq/540/smp_affinity
root@am62axx-evm:~# cat /proc/irq/540/smp_affinity
2
root@am62axx-evm:~# echo 2 > /proc/irq/16/smp_affinity
root@am62axx-evm:~# cat /proc/irq/16/smp_affinity
2

设置 IRQ 后、DSS 错误仍然存在。

在此期间、我将开始迁移并使用 SDK 版本 10.1 来验证版本 10.1 中是否存在相同的问题。我将在验证后发布结果。 整个过程大约需要 2 至 3 天。

BR

Jason

尊敬的 Jason：

是的、请继续进行这项工作。 如果 IRQ 平衡方面不起作用、则我的一系列建议正在运行。   在我看来、只能减小模型大小（或通过其他方式降低延迟）。

您是否具有访问 ti-firmware-builder 的权限？ 如果 10.1 SDK 中仍然存在问题、则我进行了更改、建议在 MCU_PLUS_SDK 软件包中实现。 我最近了解到、10.1 SDK 的 C7x 高速缓存设置不是理想的、这可能会影响某些模型的性能。

• 这是对 10.0 使用了优化设置、但我们可能对 10.1 版本使用了非优化设置、并通过 TIDL 工具提供了向后兼容性。 否则重建这个向后兼容的固件会有点困难--这需要 TI 发布特定的源代码

BR、
Reese

嗨、Reese

我最近测试了 10.1 版的媒体运行时间,发现算法运行失败,并出现以下错误。最近,我一直在研究此问题的解决方案,这可能与我们的算法库有关。

    73.373062 s:  VX_ZONE_ERROR: [ownContextSendCmd:912] Command ack message returned failure cmd_status: -1
    73.373106 s:  VX_ZONE_ERROR: [ownNodeKernelInit:604] Target kernel, TIVX_CMD_NODE_CREATE failed for node tidl_node
    73.373128 s:  VX_ZONE_ERROR: [ownNodeKernelInit:605] Please be sure the target callbacks have been registered for this core
    73.373139 s:  VX_ZONE_ERROR: [ownNodeKernelInit:606] If the target callbacks have been registered, please ensure no errors are occurring within the create callback of this kernel
    73.373154 s:  VX_ZONE_ERROR: [ownGraphNodeKernelInit:690] kernel init for node 1, kernel com.ti.tidl:1:3 ... failed !!!
    73.373199 s:  VX_ZONE_ERROR: [ graph_83 ] Node kernel init failed
    73.373210 s:  VX_ZONE_ERR[   68.481751] max 96714 get format
OR: [ graph_83 ] Graph verify failed
[TIOVX_MODULES][ERROR] 791[   68.488014] max96712 stream on
: tiovx_modules_verify_graph: Graph Verify failed
 [Leve[   68.495939] max96714 2-002a: stream on!!!!
l]:Error,[FILE]:/home/zyh/tiovx/edgeai-tiovx-apps-develop/alg/src/alglib.cpp [Func]:algInit [Line]:300 [Info]:tiovx_modules_link_pads failed!

我可以访问 TI Firmware Builder

这是否意味着更推荐使用 11.1 SDK 版本？ 此外、我想查询下一个 SDK 版本更新的计划发布日期。

BR

Jason

尊敬的 Jason：

运行此测试时、请在后台运行/opt/vx_app_arm_remote_log.out、这样我们就可以看到更多 TIOVX 日志记录。  

您是否使用与 10.0 和更新的固件相同的工件？ 您可能需要针对真正的 10.1 工具（如 10_01_00_04）重新编译。 如果 vx_app_arm_remote_log.out 中有如下行、则需要重新编译模型（否则所有设置都可以相同；只需指向单独的 tidl_tools 目录）

VX_ZONE_ERROR:[tivxKernelTIDLCreate:910] Network version - 0x20240215, Expected version - 0x20240401

• [1]相关常见问题解答
• 模型工件对版本控制采取了转化的立场、即使对于 10_01_03_00 和 10_01_04_00 等类似版本也是如此

我会暂缓推荐使用 11.1 SDK 端口。 它是稳定和良好的表现,但将是更大的变化在你的身边。 让我们确保问题不是关于工件的版本控制细节

11.2 SDK 时间线最早是 2025 年 12 月

[1]  【常见问题解答】 EDGE-AI-STUDIO：对于在 AM6xA SoC 上使用 C7x 的边缘 AI 和 TI 深度学习 (TIDL)、SDK 版本是否很重要[AM62A、AM67A、AM68A、AM68PA、AM69A ]？  

尊敬的 Jason：

响应时间没有问题。 这是我期望的输出。  

您现在使用的是 10.1 SDK、对吗？ 我假设您使用 10_01_03_00 edgeai-tidl-tools 进行编译、基于我可以从 arm-tidl 中的标签中学习的内容。 “预期版本“与 10_01_00_01 / 10_01_02_00 和 10_01_04_00 对齐、而您的版本与 10_01_03_00 对齐。 [1、2、3]

是的、这意味着您需要使用 10_01_04_00 tidl_tools 版本进行编译以连接到目标 10.1 SDK。 看起来针对更新的 10.0 SDK 进行的 10_01_03 编译并不  会产生适用于 10.1 SDK 的工件。  

[1] https://git.ti.com/cgit/processor-sdk-vision/arm-tidl

[2] https://git.ti.com/cgit/processor-sdk-vision/arm-tidl/tree/rt/inc/itidl_ti.h?h=REL.PSDK.ANALYTICS.10.01.00.04#n2019

 [3] https://git.ti.com/cgit/processor-sdk-vision/arm-tidl/tree/tiovx_kernels/tidl/dsp/vx_tidl_target.c?h=REL.PSDK.ANALYTICS.10.01.00.04#n955 

BR、

Reese

尊敬的 Reese：

目前、我已使用版本 10.01.00.05 重新建立了绘图过程、并要求算法团队成员使用 tidl 版本 10_01_00_04 导出算法模型和库。 但是、此错误仍然存在。 您能否尝试在您的最终重现此问题？ 根据我当前的测试、只要算法在 CPU 使用率高的情况下运行、就会出现问题。

[  229.334824] tidss 30200000.dss: CRTC1 SYNC LOST: (irq 200800)
[  229.340686] tidss 30200000.dss: Plane1 underflow (irq 200800)
root@am62axx-evm:/opt/edgeai-gst-apps# ps -ef | grep "irqbalance"
root         402       1  0 02:06 ?        00:00:00 /usr/sbin/irqbalance --foreground
root        1617    1274  0 02:12 ttyS2    00:00:00 grep irqbalance

BR、

Jason

嗨、Reese

以下是一种简单的复制方法：打开多个 telnetd 终端、在一个终端上运行以下应用程序、并在另一个终端上执行视频输出的 gstreamer 命令以重现问题。

gst-launch-1.0 videotestsrc  pattern=0 is-live=true ! \
video/x-raw,width=1920,height=1080,format=NV12,framerate=10/1 ! \
kmssink driver-name=tidss sync=true can-scale=false

下面是演示、模型和测试图片

e2e.ti.com/.../test_5F00_demo.tar.gz

压缩包中包含一个edgeai-tiovx-ti_libtest应用程序、两个算法模型二进制文件和一个输入测试图像。 run 命令示例如下：

./edgeai-tiovx-ti_libtest /root/BSD_10_01_w352h60_io_1.bin /root/BSD_10_01_w352h60_net.bin testv.png output.png 352 608

在同时运行算法和视频输出后、可以观察到屏幕撕裂、这将帮助您的团队确定问题。

SDK 版本： 10.01.00.05

BR

Jason

尊敬的 Jason：

我想我已经复制了此内容、但由于 libalgtiovxbase.so.0.1.0 缺少库、我无法运行您的应用程序

我这边运行了测试图形流水线。 增加较高的 CPU 负载时、帧没有丢失或同步丢失。 当我增加较高的 DDR 负载时、我 确实 会看到丢弃的帧、但没有同步丢失或 CRTC1 同步丢失消息

现在、当我关闭生成加载并运行重模型（语义分割，deeplabv3）的 stress-ng 命令时、我 确实 看到了您提到的这个错误。 有趣的是、这里没有实际的帧被丢弃、但存在屏幕撕裂现象。 其他重型型号也有类似的效果

更改 tidss（显示子系统）的 IRQ 亲和性以避免 CPU0（C7x 等其他内核处理中断的位置）似乎不会影响此问题。 我需要将此记录在我们的开发团队中、以便进行更深入的调查。 这必须是根本原因。  

我也运行了一个快速测试版本 11.1 SDK、这个问题也在相同的条件下出现。

轻量化模型不会产生这种效果,这很有趣,因为较重的模型与较快的模型相比,每单位时间通过的 IRQ 较少。  

总而言之、这存在于多个 SDK 版本上、我们对其进行了复制。 根本原因需要付出一些努力。 需要注意的是、在 10.1 TIDL 被引入之前、10.0 SDK 中不会存在该效应

BR、
Reese

嗨、Reese

感谢您的详细调查。 我们期待您和您的 开发 团队解决此问题。

同时、我很抱歉忘记提前提供 SO 文件。 在这里。

您的论坛不支持直接上传.so.0.1.0 文件,因为它会触发错误。 因此、我已将其压缩到一个存档中。

e2e.ti.com/.../libalgtiovxbase.so.0.1.rar

BR

Jason

谢谢 Jason。 我认为我拥有我们的开发团队更深入调查所需的信息。  

他们建议、这与进入显示子系统的 DDR 的 QoS 相关、可能需要更改、以便增加优先级（我仍在寻求如何实现此功能）。 他们注意到、该问题可能是由于对于 TIDL 模型、C7xMMA 上的 DDR 流量较高、这可能是获得不同的 QoS 与 A53 DDR 流量（或者至少产生了由 DDR 负载造成的应力）。

具有更多内部存储器重复使用情况（即 DDR 利用率较低）的较小模型将 缓解此问题、但我担心它无法完全消除、尤其是在应用过程中 DDR 利用率会很高的情况下。  

感谢您的耐心。  

BR、、
Reese

尊敬的 Jason：

想给一个更新,虽然我们是在美国的一个假日周

我进一步研究了原始 10.0 SDK 与 TIDL 10.1.3 的增补版本之间的对比。 实际上、我在 10.0 上看到了同样类型的问题、尽管很少、而且仅限于 DDR 较重的型号（较高的分辨率通常会伴随较高的 DDR 负载）

我们在另一个 SoC (TDA4VH) 上遇到类似的问题、在这个问题中、C7x 流量导致显示耗尽和同样类型的屏幕撕裂效应。 解决该问题的工程师证实、它确实来自 DDR 流量的 QoS/CoS 优先级。 这确实说明了为什么只有来自 C7x 的 DDR 流量会导致此类屏幕撕裂、而来自 A53 的更高 DDR 负载也不会。  

我认为这个问题实际上是由根本原因引起的、因此现在的任务是实施并提供解决方案。 该修复程序预计位于 SDK 内的 u-boot 中 board-support/ti-u-boot-2024.04+git/drivers/ram/k3-ddrss 部分附近、因此当准备就绪时、它将需要重新编译 u-boot 组件。

感谢您的持续耐心。  

嗨、Reese

感谢您的更新、我非常感谢您在假期期间回复我的信息。 我注意到了这种情况、并期待着解决这一问题。

我注意到您提到了在 U-boot 中进行更新以解决此问题。 是否也可以通过启动 SBL 来解析该问题？ 在我们的应用程序中、我们从 SBL 开始、并减少了 U-Boot、从而缩短启动时间。

希望你喜欢你的休息！

BR

Jason

尊敬的 Jason：

需要更改 DDR 流量优先级的低级别配置。 SBL 和 u-boot 的实现方式可能不同、但我假设它们在默认情况下使用相同的配置。  

到目前为止、寄存器（来自 AM62A TRM 第 14.5.5 节）和功能说明 (9.1 和 9.1.3.2 服务类别 (CoS)) 建议默认 SDK 不会根据我在运行时查询的 MMR 寄存器值优先考虑任何特定接口的 DDR 流量。 我需要与更熟悉这里的低级配置的人合作。  

BR、
Reese

嗨、Reese

运行这些命令后、屏幕撕裂效果不再退出！

devmem2 0x0f300024 w 0xf0000000 # change route 1 to include all A53 writes. 
devmem2 0x0f300034 w 0x11111111 # downgrade route 1 priorities from 0x0's
devmem2 0x0f300030 w 0x0        # change default priorities back to 0x0's (highest)

然而,当我使用stress-ng命令将 CPU 负载增加到 70%时,出现了一个新问题:视频帧变得混乱。 有关详细信息、请参阅随附的视频。我认为这个问题不是由 DDR 修改引起的、因为我也在不输入任何命令的情况下观察到了相同的问题。

e2e.ti.com/.../648ab8b7b91f9a6df9c24db5eb7ec5fd.mp4

BR、

Jason

尊敬的 Jason：

很棒、感谢确认！

stress-ng命令将 CPU 负载增加到 70%、出现了一个新问题

好的、明白。 看起来像帧跳过/回放。 我建议为这个问题制定一个新的线索--我们已经解决了这个问题的根源

在您的完整应用中、您是否会看到 CPU 利用率如此高？ 您的应用是否也显示了帧跳过？

嗨、Reese

好的、我为此 AM62A7 制作了一个新主题：CPU 使用率很高时跳过帧 — 处理器论坛-处理器 — TI E2E 支持论坛

在我的应用中、CPU 使用率通常不会很高。 然而、这仍然是一个令人关注的问题。 毕竟、在 CPU 使用率较低的情况下、此问题可能不会很容易发生、但也不会完全消失。因此、能够解决此问题将是最佳结果。

BR

Jason