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