1

I have just been reading up on the advantages of immutable texture storage. Whilst I understand that, using mutable storage, I would be able to resize the texture storage on demand, I don't see why I would want to.

What techniques make use of mutable texture storage in a way that is not possible or poorly performing in immutable texture storage?

4

2 回答 2

3

请允许我引用 ARB 在ARB_texture_storage 扩展中的讨论。请注意，这些是来自实现 OpenGL 的 IHV的问题和讨论，他们比我们大多数人更了解他们的 GPU：

4：使用这些入口点是否应该使元数据（格式和维度）不可变？

已解决：是的。

讨论：知道元数据不能改变的好处可能会超过在每个纹理规范调用上检查 TEXTURE_IMMUTABLE_FORMAT 标志的额外成本。

5：使用对 TexStorage* 的新调用完全替换纹理是否合法？

解决。它不会被允许的。

讨论：这对于使纹理的所有级别无效很有用。允许在此处更改元数据似乎比尝试定义更改元数据的可移植定义更容易（例如，如果您第一次使用未调整大小的内部格式而第二次使用相应大小的内部格式怎么办，或者反之亦然反之亦然）？

然而，虽然这在很大程度上类似于删除旧的纹理对象并用新的对象替换它，但它确实失去了一些不变性的优点。具体来说，因为这样做不会重置绑定，所以它不允许迁移路径到在绑定时验证纹理格式的 API。

6：如果不影响元数据，在 TexStorage* 之后使用 TexImage* 是否合法？

已解决：没有。

讨论：一个潜在的用例是允许使用 NULL 指针使纹理的单个级别无效。但是，如上所述，确定什么构成更改并非易事。

请允许我换一种说法：如果 ARB 认为原位纹理修改是个好主意，他们就不会glTexStorage 明确禁止它。

于 2013-07-30T18:07:42.333 回答
2

有几种情况可以使用可变纹理。这里有一些我的想法。

  1. 在 GPGPU 应用程序中，输入数据通常不是完全网格化的，而是稀疏的。在这种情况下，我不得不浪费内存——可变纹理允许调整大小以防止这种情况。
  2. 冒名顶替者/广告牌 LOD - 当一些小东西可以做时，无需分配大纹理
  3. 具有纹理的数据相关数学运算，例如基于计算的掩码/大小的卷积
  4. 缓存“昂贵”的渲染输出以进行合成。这些存储纹理的动态调整大小可以节省宝贵的 GPU 内存。

还有更多我可能遗漏了，但我希望你能明白要点。

于 2013-07-30T13:43:51.267 回答