【问题标题】:Texture Memory Usage纹理内存使用
【发布时间】:2020-01-04 01:02:09
【问题描述】:

我试图找出我的应用程序消耗了多少纹理内存。我有以下类型的纹理和计算:

  1. RGB 纹理 -> textureWidth * textureHeight * 3(内存使用)
  2. RGBA 纹理 -> textureWidth * textureHeight * 4(内存使用)

因此我想知道图形驱动程序分配的内存是否比上面计算的内存多得多?

【问题讨论】:

    标签: graphics opengl-es opengl-es-2.0


    【解决方案1】:

    几个简单的答案:

    据我所知,自从(大多数)硬件设备支持压缩 24 位 RGB 数据以来,已经过去了大约 2 年。在现代硬件中,这通常以“XRGB”(或等效)格式表示,其中每个像素有一个填充字节。在硬件中有效处理跨越缓存行等的像素是很痛苦的。此外,由于许多应用程序(阅读“游戏”)使用texture compression,因此支持完全打包的 24 位似乎有点多余。

    纹理尺寸:如果纹理的尺寸对于特定硬件来说不是“很好”(例如,也许 x 不是 16 字节的倍数,或者说,4x4 或 8x8 块),然后驱动程序可以填充纹理的物理尺寸。

    最后,如果您有 MIP 映射(并且您确实想要 this for performance 以及质量原因),它会将纹理大小扩大约 33%。

    【讨论】:

    • 感谢您的回答,我认为可能会出现填充,所以我会寻找详细信息。
    【解决方案2】:

    除了 Simon F 的回答之外,还值得注意的是,编写不当的应用程序可能会强制驱动程序为同一纹理的多个副本分配内存。如果它试图修改纹理,而它仍然被正在进行的渲染操作引用,则可能会发生这种情况。这通常称为“资源写入时复制”或“资源重影”。

    这里的博客有更详细的解释:

    https://community.arm.com/developer/tools-software/graphics/b/blog/posts/mali-performance-6-efficiently-updating-dynamic-resources

    【讨论】:

      猜你喜欢
      • 2012-02-01
      • 2010-12-29
      • 2013-04-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-05-27
      • 2011-04-25
      相关资源
      最近更新 更多