问题标签 [qualcomm]

在最近的项目中，只需要使用 qualcomm 分发的 profiler 测量相机 fps 和帧延迟。我也在高通论坛上问过这个问题并浏览了他们的文档，但没有得到回复，所以如果有人能给我一些指导，那对我真的很有帮助。

在上面的快照中，我只启用了相机以在捕获模式下对其进行跟踪。我目前面临的问题如下，

1. 从上图中是否可以测量相机 fps？如果是这样，如何实现。

2. 探查器是否可以看到从捕获到显示的完整管道。

3. 快照中显示的 cam_strmdatapro 是什么，我搜索了该关键字，但没有找到与它相关的内容。

4. 绿条代表什么？

5. 相机支持的 ​​fps 为 30，因此每帧应该需要大约 33.33 ms 才能捕获。假设绿色条代表从相机获取数据的时间，平均只需 4-6 毫秒。为什么它应该在 33 毫秒左右时却需要如此短的持续时间。

6. 是否有任何材料/教程可以了解有关分析器的更多信息。

我以前在 linux 环境和 opencv 上工作过，但我是 android 世界的新手。我正在尝试根据需要学习它。

任何帮助将不胜感激。

我有一个 NativeActivity 程序，它在运行 Android 9 的 OnePlus 3T 上运行良好。它在 Pixel 5 上运行的 Android 11 中启动时崩溃。我正在使用 Visual Studio 2019 和 SDK Build-tools 29.0.2 和 Platform-Tools 30.0。 4. AndroidManifest.xml 需要 GLES 版本 3.1，并针对 SDK 25（允许低至 21。）

代码从标准 EGL 设置开始，以获取窗口、创建表面、创建上下文等（逐字逐句来自 NativeActivity 示例），然后运行到初始化函数：

它通过了这部分。它在里面崩溃graphics_load_shader_text()：

具体来说，调用glCreateShader()最终生成一个空指针 seg-v。

当时的logcat是这样的：

看到这里，我觉得可疑的一件事是 SELinux 失败：

这是此失败的直接原因吗？“untrusted_app_25”位似乎来自用于USB开发部署的“调试签名”；那是对的吗？如果是这样，我该如何解决它以进行开发？在最终真正部署应用程序时，如何确保应用程序不受信任？

我在 Google 上搜索了一下，“只需编写一些 SELinux 清单并安装它们”似乎不是一个好主意，因为我认为 APK 通常不能（或不应该！）这样做，并且这样做显然取决于所使用的特定设备硬件和驱动程序，因此这不是其工作的预期方式。

那么，我错过了什么？

我正在开发一个使用 Intrinsyc OpenQ-2500 开发套件的项目。该套件使用 APQ8909W snapdragon 处理器，运行 Oreo 8.1 的修改版本。

我正在尝试调出我们已连接的新 2 通道 MIPI 显示器。我大致遵循了 Intrinsycs 显示移植指南之一中概述的步骤：https ://developer.qualcomm.com/download/db410c/dsi-display-porting-guide-linux-android.pdf

这一直不成功，我们知道调试。在需要为新显示器配置的文件之一中，有一些 dprintf() 行，如下所示：

据我了解，根据 debug.h，INFO 或 CRITICAL 是调试级别：

谁能告诉我 dprintf() 的实际输出将被定向到哪里？

我一直在 Intrinsyc Open-Q™ 845 uSOM 硬件开发套件上练习 Hexagon DSP SDK 的示例代码。当我尝试使用相机流式传输示例时，我能够执行代码并在 DSP 中运行它，即使我没有得到有效的输出。预期的输出是像素数据处理效果。对于 hvx_add_constant 示例，明亮区域将定期提升为粉红色。但是当相机打开时我得到一个没有预览图像的输出，就像一个黑色的窗口一样。

提前致谢。

我一直在使用以下格式将 AT 命令从应用处理器 (AP) 发送到调制解调器子系统：

它一直有效，但我从未意识到/dev/smd7端口来自哪里。网上查了一下，貌似是指Radio Interface Layer（RIL）使用的端口，但是怎么确认呢？

我最近开始遇到超时问题，我开始怀疑端口是否不正确或可能已更改

注意AP运行的是linux

编辑： 看起来调制解调器不断重启，因此出现读取错误。但似乎在运行上面的两个命令后发生

我观察到对于相同价格范围内的设备，基于 Snapdragon 的解码器可以比基于 Exynos 的解码器具有更高的解码延迟。这在解码 H264 流时，SPS 中的值“pic_order_cnt_type”设置为 0 而不是 2 时最为明显。我想知道您是否也观察到这种行为以及是否有任何解决方法（我已经在这里打开了一个问题但目前没有回应）

一些技术细节：

我已经构建了一个简单的示例应用程序，它使用 AMediaCodec 来解码 h264 流。它将“解码延迟”作为测试结果上传到 Firestore 数据库。代码

以下是 Pixel 4（使用 snapdragon 解码器）和三星 Galaxy Note 9（使用 exynos 解码器）上不同 h264 流的解码延迟比较：

像素 4	银河注 9

如您所见，对于名为 jetson/h264/2/test.h264 的视频，snapdragon 设备的解码时间比三星设备高约 21 倍。此流的 pic_order_cnt_type==0。然而，在其他流上，解码时间的差异是微不足道的。（他们都使用 pic_order_cnt_type==2）

决定骁龙解码器是否进入“低延迟解码路径”的主要参数似乎是上面提到的 pic_order_cnt_type 值。如果我正确理解 h264 规范，如果此值设置为 2 图片重新排序是不可能的（没有缓冲帧）。如果设置为 0，图片重新排序是可能的，但编码器不必使用。但是，snapdragon 解码器并没有区分“可能”和“编码器实际使用”，导致解码延迟差异很大。

我能够通过在将比特流发送到解码器之前对其进行操作来减少 snapdragon 的解码延迟（添加带有 num_reorder_frames=0 和 max_dec_frame_buffering=0 的 VUI），但它永远不会导致 0 个缓冲帧，只会产生更少的缓冲帧。

我正在尝试将桌面应用程序转换为 Android Automotive OS (AAOS)。我正在使用 OpenCV DNN 进行对象跟踪。另外，我正在使用 OpenGL 来呈现内容。渲染输出（2 个全高清）必须显示在两个监视器上（必须全屏）。另外，我必须使用串行通信发送一些数据。我对 AAOS 没有任何经验。所以我不能决定这个应用在 AAOS 上是否可行。所以如果你对 AAOS 有任何经验，你能给我关于这个项目的任何反馈。AAOS 在 Snapdragon SA8155 上运行。

开发板链接： https ://www.lantronix.com/products/sa8155p-automotive-development-platform/#tab-features

1. 创建了一个简单的虚拟序列模型，tf.keras如下所示：

2. 训练模型并使用tf.keras.models.saved_model.

3. 获取input输入并output node names使用saved_model_cli.

   

4. saved model使用freeze_graph.py实用程序冻结。

   模型被冻结。

现在这是主要问题：

5. 要加载冻结图，我使用了本指南Migrate tf1.x to tf2.x ( wrap_frozen_graph)
6. 用过的
7. 输出错误 ValueError: Input 1 of node StatefulPartitionedCall was passed float from dense_3/kernel:0 incompatible with expected resource.

将 .pb 转换为 .dlc (Qualcomm) 时出现同样的错误。实际上我想在高通的 Hexagon DSP 或 GPU 上运行原始模型。

所以这次崩溃一直是我存在 3 个月的祸根。

它单枪匹马地让我们超过了谷歌的不良行为门槛。我从来没有亲身经历过，我只知道我们每个月都有数百名用户经历了这次崩溃。

崩溃发生在 libGLESv2_adreno 内部，这是一个为在 Adreno GPU 上运行的嵌入式系统执行 OpenGL 的库，该 GPU 是 Qualcomm 专用的 GPU。

因此，它只影响带有 Adreno GPU 的 Android 9 设备，这里有一些违规者：

• 三星盖乐世 S8
• LGE LG Stylo 5
• LGE LG G7 ThinQ
• 摩托罗拉 Moto Z(3)
• 带蓝宝石护罩的京瓷 DuraForce PRO 2

这是一个使用 MapboxGL 的 React Native 项目。事实上，我什至在这里发现了同样的问题： https ://github.com/mapbox/mapbox-gl-native-android/issues/264

可悲的是，这不是我们使用的包..这是我们使用的： https ://github.com/react-native-mapbox-gl/maps

而且我不知道这是一个mapbox问题，这个回溯中真的没有任何线索：

有谁特别擅长阅读神秘的回溯来确定问题的根源吗？关于如何更好地调试它的任何建议？

如果有办法对上面的代码进行去符号化，我会很高兴，但我认为这需要 GPU lib 符号文件..也许我错了..

非常感谢！

更新：这个问题仍然存在（它仍然出现在 Sentry 中），但现在 Google Play 控制台已将其过滤掉，因此我们的应用程序现在低于不良行为标记。我最好的猜测是，谷歌决定不因 GPU 级别的问题而惩罚应用程序？