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

Question

所以，glGenerateMipMap 很棒。我想知道一些事情:

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

背景——除了其他需要对上述问题有更多了解的用例之外，我还想“跟踪应用程序消耗的大约 GPU VRAM”(出于各种原因，例如可扩展的任意纹理/顶点流)——不仅跟踪应用程序填充的 GL 缓冲区，还跟踪上传的纹理(当然这只是一个近似值，但已经足够好了)。跟踪它们的 mip-map 也是必要的，因此了解如何清除它们或者它们何时被当前一代 GL 实现清除将非常有用。

Answer 1

suppose the texture image is changed via glTexSubImage2D, another call to glGenerateMipMap is -- sufficient / required / unnecessary?

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

However, the previously generated mip-maps remain in GPU VRAM, right? -- can the driver be "hinted" to delete those?

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

为了更清楚地解释原因，请考虑相对较新的 OpenGL 函数 glTexStorage2D 。使用此函数使纹理的存储不可变。它具有您所说的 mipmap 数量，永远(当然，直到您将其删除)。

为什么？好吧，从 ARB_texture_storage 扩展:

4: Should use of these entry-points make the metadata (format and dimensions) immutable?

RESOLVED: Yes.

DISCUSSION: The benefits of knowing metadata can't change will probably outweigh the extra cost of checking the TEXTURE_IMMUTABLE_FORMAT flag on each texture specification call.

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

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

无论如何，这并不重要，因为 OpenGL 无法取消分配 mipmap 图层。