4

所以，glGenerateMipMap很棒。我想知道几件事：

  • 假设纹理图像通过glTexSubImage2D更改，对 glGenerateMipMap 的另一个调用是 - 足够/需要/不必要？
  • 假设最终用户应该能够即时“启用/禁用 mip-map”，当然 GL_TEXTURE_MIN_FILTER 必须相应地设置为 mipmap 与否。但是，之前生成的 mip-map 仍保留在 GPU VRAM 中，对吗？- 可以“提示”驱动程序删除这些吗？我是否必须重新上传原始纹理图像（但现在不再将 min-filtering 设置为 mipmap）以清除包含先前生成且现在不需要的 mip-map 的内存？

背景——在其他也需要对上述问题有更多见解的用例中，我还想“跟踪应用程序消耗的大约 GPU VRAM”（出于各种原因，例如可扩展的任意纹理/顶点流) --- 通过跟踪应用程序填充的 GL 缓冲区以及上传的纹理（确保它只是一个近似值但足够好）。跟踪它们的 mip-maps 也是必要的，因此知道如何清除它们或它们何时被当前 GL 实现清除将非常有用。

4

1 回答 1

4

假设纹理图像通过 glTexSubImage2D 更改，对 glGenerateMipMap 的另一个调用是 - 足够/需要/不必要？

如果您希望 mipmap 正确反映上传的基础级别，可以。glGenerateMipmaps是一次性操作，而不是您在纹理上翻转的开关。

但是，之前生成的 mip-map 仍保留在 GPU VRAM 中，对吗？- 可以“提示”驱动程序删除这些吗？

不要打扰。像这样告诉驱动程序取消分配内存总是一个坏主意。事实上，为同一个 mipmap 级别多次调用 glTexImage*（除非您正在上传立方体贴图面）是一个坏主意。

为了更清楚地解释这是为什么，请考虑相对较新的 OpenGL 函数glTexStorage2D。这个函数的使用使得纹理的存储不可变。它永远有你说的那样的 mipmap 数量（当然直到你删除它）。

为什么？好吧，来自 ARB_texture_storage 扩展：

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

已解决：是的。

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

ARB 看到了这方面的好处。事实上，没有它， ARB_texture_view可能是不可能的（或者至少效率很低）。很明显，这就是他们希望人们使用的东西。

如果您希望用户能够翻转该开关并实际重新获得一些内存，那么请正确执行：创建一个与旧纹理对象具有相同内容的新纹理对象。

无论如何，无论如何都无所谓，因为OpenGL没有办法释放mipmap层。

于 2012-10-22T07:09:44.637 回答