c++ - OpenGL 4.3 上的 ETC2 纹理压缩的视频内存

Question

目前我正在编写一个渲染器，它使用许多纹理，并将填满我的显卡视频内存(我的 nVidia GTX 780 Ti 为 3 Gb)。因此，我使用 Mali's texture compression tool 预压缩了所有必要的图像。并将我的渲染器与 libktx 集成用于加载压缩纹理(*.ktx)。

压缩效果非常好。对于 RGB 图像(使用GL_COMPRESSED_RGB8_ETC2压缩)，它一致达到 4 bpp，对于 RGBA 图像(GL_COMPRESSED_RGBA8_ETC2_EAC)达到 8 bpp，如规范中所述。但每当这些压缩图像上传到 GPU 时，它们都会显示为原始大小(压缩前)

我正在使用以下方式加载压缩纹理:

ktxLoadTextureN(...);

我可以看到在该函数内，libktx 将调用:

glCompressedTexImage2D( GLenum target, GLint level,
                        GLenum internalformat,
                        GLsizei width, GLsizei height,
                        GLint border,
                        GLsizei imageSize,
                        const GLvoid * data);

glCompressedTexImage2D()中的imageSize参数；与我的压缩数据大小相符，但是执行该函数后，显存会增加解压后的图像大小。

所以我的问题是:压缩纹理在上传到 GPU 之前是否总是解压缩？如果是这样，是否有任何标准化纹理压缩格式允许在 GPU 上动态解码压缩纹理？

Answer 1

ETC2 和 ETC 格式不常被桌面应用程序使用。因此，桌面 GPU 和/或其驱动程序本身可能不支持它们。但是，它们是 GLES 3.0 兼容性所必需的，因此如果您的桌面 OpenGL 驱动程序报告 GL_ARB_ES3_compatibility ，那么它还必须支持 ETC2 格式。由于许多开发人员希望在桌面上开发 GLES 3.0 应用程序，以避免不断部署并更容易调试，因此希望驱动程序报告此扩展。

您的驱动程序可能只是通过将软件中的数据解压缩为未压缩的 RGB(A) 目标来模拟对 ETC2 格式的支持。这可以解释未压缩纹理的内存使用量没有变化的原因。这不一定适用于每个桌面驱动程序，但可能适用于大多数驱动程序。它仍然符合规范 - 尽管是假设的，但不要求压缩纹理消耗传递到 glCompressedTexImage2D 的内存。

如果您想在桌面上模拟相同级别的内存使用情况，则应使用 GL_texture_compression_s3tc 将纹理压缩为常用的桌面压缩格式，例如 S3TC 格式之一。扩展，该扩展应该在所有桌面 GPU 驱动程序上可用。