[参考译文] TDA4AEN-Q1：与常规纹理相比、使用 glEGLImageTargetTexture2DOES 生成纹理需要更多的时间并增加带宽。

您好、谢：

感谢您提出您的问题。 我指派了一位该主题的专家。

此致、
Sivadeep  

您好：  

在过去与 IMG 的对话中、不支持使用 DMA BUF 来生成"压缩"纹理的实用程序。 我有一个未结 TT、正在等待 IMG 澄清这是否是任何一般纹理的情况。

我会在听到回复时更新此主题。

谢谢您、
Sarabesh S.

好的、感谢您的答复。 如有任何进展、请尽快答复我。

您好：  

这一问题仍在研究之中。 但是,IMG 最初认为这个问题可能是由于数据类型分散而导致的,因此占用了大量的 b/w。 这与使用较少 DDR b/w 的带区数据相反。 您能否澄清或确认这一点？

谢谢、
Sarabesh S.

我们使用虚拟地址的内容来更新纹理数据。 此方法生成的纹理具有较小的带宽。

使用下面显示的方法生成和更新纹理。 如上所述、使用纹理时的带宽消耗将增加超过200米。

您也可以尝试以下操作来读取图像的数据。
第一种方法是将图像数据复制到共享存储器、生成相关的 DMA 信息、然后对其进行渲染。 观察其带宽消耗情况。
第二种方法是使用 glTexImage2D 接口加载图像数据以生成纹理、然后进行渲染以观察其带宽消耗。

您应该能够在尝试后观察到相同的现象。 我不知道产生差异的原因是什么。

您好：
感谢您的答复。您有任何支持 FBC 的示例吗？ 此"FBC"是指渲染环境的不同内存分配方法、还是指其他方法？

您好：  

抱歉、FBC 在此处不是正确的术语。 我实际上是指"纹理压缩"。 目前显示控制器无法处理 FBC、因此在 tidss 固定之前、无法选择 FBC。 但是、由 CPU 分配给 GPU 的纹理支持压缩。 您是否能够确认 是否压缩纹理、从而导致带宽降低？ 我认为不同之处可能是 dma-buf 方法使用未压缩的数据、而不是 glTexImage2D 方法。

此致、
Sarabesh S.

您好：

从应用层来看、我们无法知道较低级别的具体实现差异、而这种差异正是该帖子讨论的内容。 这篇文章描述了产生差异的整个过程。 我最初的假设也是,DMA-BUF 数据在与纹理关联时没有被压缩,这导致我提出了这个关于是否需要额外处理的问题。