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

目前，我正在编写一个渲染器，它使用许多纹理，并将填充我的图形卡的视频内存（我的nVidia GTX 780 Ti为3 Gb）。因此，我使用渲染器对所有必要的图像进行了预压缩，并将其与用于加载压缩纹理（*.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);

GLCompressedExImage2D（）中的imageSize参数；匹配我的压缩数据大小，但在执行此函数后，视频内存将增加解压缩的图像大小

---

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

ETC2

和

ETC

格式不常用于桌面应用程序。因此，桌面GPU和/或其驱动程序可能不支持它们。但是，它们是GLES 3.0兼容性所必需的，因此如果您的桌面OpenGL驱动程序报告，那么它还必须支持

ETC2

格式。由于许多开发人员希望在他们的桌面上开发GLES 3.0应用程序，以避免不断的部署和更容易的调试，因此驱动程序最好报告此扩展

很可能您的驱动程序只是通过将软件中的数据解压缩到未压缩的RGB（A）目标来模拟对

ETC2

格式的支持。这可以解释未压缩纹理的内存使用情况不变。这并不一定适用于所有桌面驱动程序，但可能适用于大多数桌面驱动程序。它仍然符合规范-尽管假定压缩纹理会消耗传递到

glCompressedTexImage2D

中的内存，但不需要这样做

---

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

非常感谢您将我从调试中解救出来，让我再过一天。我永远也猜不到这些压缩纹理是在我的图形卡上模拟的，因为我甚至在不同的GPU上尝试过它们。接下来我将尝试DXT压缩格式。再次感谢！