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 驱动程序上。