如何在 OpenGL 中动态启用/禁用纹理 mip-maps？

Question

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

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

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

Answer 1

假设纹理图像是通过 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 层。