如何在计算着色器中最好地访问 ARCore 视频帧

Question

我正在实施一项技术，该技术使用 ARCore（当前为 1.16.0）以及 OpenGL ES 3.2 计算着色器中的自定义图像处理。

有两种方法可以从计算着色器访问视频帧，但都有缺点：

1. 使用Session.setCameraTextureName()。 这似乎是一个自然的选择，因为我让 ARCore 为我将数据放入 OpenGL 纹理中。但是它在 RGBA 中，这可能意味着在我获取数据之前发生了不需要的有损转换。此外，由于它是 GL_TEXTURE_EXTERNAL_OES 纹理，我无法直接访问像素（使用imageLoad()），必须通过采样器。此外，在我测试过的设备上，每个 CameraConfig 的纹理分辨率都是 1080，这对于我的计算算法来说太大了，需要缩减。
2. 使用Frame.acquireCameraImage()。 这里的优点是我在 YCbCr 中获得图像，大概跳过了有损转换步骤，并且我可以选择合适的分辨率。缺点是我需要拨打两个glTexSubImage2D() 电话。

（有趣的是，在三星 S8 和 A3 上，所有配置的纹理分辨率为 1920x1080，图像分辨率为 640x480、1280x720 和 1920x1080。）

ARCore + 计算似乎有点灰色地带。欢迎任何关于哪个是更好选择的建议，但请引用来源。 :)

编辑：根据反馈添加一些具体问题：

• 从主存中的 YCbCr 图像到 RGBA OpenGL ES 纹理一般在后台使用什么路径？
• 这条路径比glTexSubImage2D()快吗？
• 无论我是否设置会话的纹理名称，我都要为此支付计算成本吗？
• 主内存 YCbCr 图像是否总是在转换链中出现在 RGBA 纹理之前？

Answer 1

从主存中的 YCbCr 图像到 RGBA OpenGL ES 纹理一般在后台使用什么路径？

使用GL_TEXTURE_EXTERNAL_OES 基本上是零拷贝访问。 GPU 可以直接访问相机/视频块写入的 YUV 图像。颜色转换发生在飞行中；这样做可能会有一些 GPU 开销——这将取决于硬件——但没有在内存中创建第二个 RGB 副本。多少开销 - 现代移动 GPU 可以非常有效地做到这一点，但较旧的移动 GPU 可能需要 2 倍于两个平面 YUV 的纹理成本。

这条路径比 glTexSubImage2D() 快吗？

一般来说，是的，这就是存在直接访问路径的原因。但是，您必须在一种情况下而不是另一种情况下注入额外的下采样，这一事实并不能使这成为一个明显的“正确答案”。

另请注意，费用不同。直接 YUV-RGB 转换会产生 GPU 成本。纹理上传会产生 CPU 成本。根据您设备的相对 CPU/GPU 性能以及应用程序的其余部分使用的资源，其中一个可能比另一个痛苦少。

无论我是否设置会话的纹理名称，我是否为此支付了计算成本？

没有。访问纹理时，在采样器中完成 YUV 到 RGB 的转换。

主存 YCbCr 图像是否总是在转换链中出现在 RGBA 纹理之前？

RGBA 纹理完全是虚拟的 - 它不存在于内存中。

所有配置的纹理分辨率为 1920x1080，图像分辨率为 640x480、1280x720 和 1920x1080。

请注意，相机 HAL 层中有很多特定于供应商的“魔法”。无法说低分辨率图像是如何创建的。它们可以由相机直接以较低的分辨率生成，也可以由供应商 HAL 在单独的通道中缩小（如果相机不能直接执行，通常使用硬件缩放器）。