目前，我正在编写一个渲染器，它使用了许多纹理，并将填满我的显卡的视频内存（我的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);型
glCompressedTexImage 2D（）;中的imageSize参数与我的压缩数据大小相匹配，但在执行此函数后，视频内存将增加解压缩图像大小。
所以我的问题是：压缩的纹理在上传到GPU之前总是解压缩的吗？如果是的话，是否有任何标准化的纹理压缩格式允许压缩的纹理在GPU上动态解码？
1条答案
按热度按时间67up9zun1#
ETC2和ETC不常用于桌面应用程序。因此，桌面GPU和/或其驱动程序可能不支持它们。但是，它们是GLES 3.0兼容性所必需的，因此如果您的桌面OpenGL驱动程序报告GL_ARB_ES3_compatibility，那么它还必须支持ETC2。因为许多开发人员希望在桌面上开发GLES 3.0应用程序，以避免不断部署并更容易调试，希望驾驶员报告该扩展。很可能你的驱动程序只是模拟对
ETC2的支持，通过将软件中的数据解压缩到未压缩的RGB（A）目标。这可以解释未压缩纹理的内存使用不变。这不一定对每个桌面驱动程序都是正确的，但对大多数驱动程序来说可能是正确的。它仍然符合规范-尽管它是假设的，不要求压缩纹理消耗传递到glCompressedTexImage2D中的存储器。如果您想在桌面上模拟相同的内存使用水平，则应使用GL_texture_compression_s3tc扩展将纹理压缩为常用的桌面压缩格式，例如S3 TC格式之一，该扩展应在所有桌面GPU驱动程序上可用。