我创建了一个 1024*1024 纹理
glCompressedTexImage2D(GL_TEXTURE_2D, 0, GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IMG, 1024, 1024, 0, nDataLen*4, pData1);
然后像这样更新它的第一个 512*512 部分
glCompressedTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 512, 512, GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IMG, nDataLen, pData2);
此更新生成glerror 1282(invalid operation)，如果我更新整个 1024*1024 区域都可以，似乎 pvrtc 纹理无法部分更新。
是否可以部分更新 pvrtc 纹理，如果它是怎么样的？
令人惊讶的是，我将一个小的 pvrtc 纹理数据复制到一个大的中，它的工作原理就像 glCompressedTexSubImage2D。但我不确定在我的引擎中使用这个解决方案是否安全。
在我看来，你不能在 GLES2 上使用（链接到规范，请参阅 3.7.3。）
如果 xoffset 或 yoffset 不等于 0，或者宽度和高度分别与纹理的宽度和高度不匹配，则调用 CompressedTexSubImage2D 将导致 INVALID_OPERATION 错误。调用修改的区域之外的任何纹素的内容都是未定义的。对于图像易于修改的特定压缩内部格式，可以放宽这些限制
使 glCompressedTexSubImage2D 听起来对我来说有点没用，tbh，但我想它是用于更新单个 mips 或纹理数组级别。
对或错，PVRTC1 不支持 CompressedTexSubImage2D 的原因是，与 ETC* 或 S3TC 不同，纹理数据没有被压缩为独立的 4x4 纹理像素方块，而后者又被表示为 64 位或 128 位数据取决于格式。使用 ETC*/S3TC 可以替换任何对齐的 4x4 纹理像素块，而不会影响纹理的任何其他区域，只需替换其相应的 64 位或 128 位数据块即可。
对于 PVRTC1，两个目标是避免块伪影并利用相邻区域通常非常相似的事实，因此可以共享信息。尽管压缩数据被分组为 64 位单元，但这些会影响纹理像素的重叠区域。在 4bpp 的情况下，它们是 ~7x7，而对于 2bpp，它们是 15x7。
正如您稍后指出的，您可以自己复制数据，但可能存在模糊边界：例如，我采用了这些 64x64 和 32x32 纹理（已使用 PVRTC1 @4bpp 压缩和解压缩）...
+
然后做了相当于“TexSubImage”得到：
如您所见，较小纹理的边界已被弄脏，因为颜色信息在边界之间共享。
在实践中这可能无关紧要，但由于它不严格符合 TexSubImage 的要求，因此不受支持。
PVRTC2 具有更好的子图像替换功能，但至少没有在一个知名平台上公开。
<Unsubtle plug> 顺便说一句，如果你想了解更多关于纹理压缩的信息，Stack Exchange Computer Graphics网站上有一个线程</Unsubtle plug>