目前我正在编写一个渲染器，它使用了许多纹理，并将填满我的显卡的视频内存(我的nVidia GTX 780 Ti的3 Gb)。因此，我使用Mali的纹理压缩工具预压缩了所有必要的图像，并将我的渲染器与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上进行解码?
桌面应用程序不常用ETC2和ETC格式。因此，它们可能不被桌面GPU和/或其驱动程序原生支持。然而，它们是gls3.0兼容性所必需的，所以如果你的桌面OpenGL驱动程序报告gl_arb_es3_兼容性，那么它也必须支持ETC2格式。由于许多开发人员希望在他们的桌面上开发GLES 3.0应用程序，以避免不断部署，并且更容易调试，因此希望驱动程序报告此扩展。
很可能您的驱动程序只是通过将软件中的数据解压缩到未压缩的RGB(A)目标来模拟对ETC2格式的支持。这就解释了为什么未压缩纹理的内存使用没有变化。这并不一定适用于每个桌面驱动程序，但可能适用于大多数驱动程序。它仍然符合规范-尽管它是假设的，没有要求压缩纹理消耗传递给glCompressedTexImage2D的内存。
如果你想在你的桌面模拟相同级别的内存使用，你应该压缩你的纹理到一个常用的桌面压缩格式，如S3TC格式之一，使用GL_texture_compression_s3tc扩展，这应该是所有的桌面GPU驱动程序可用。