I’ve got compressed textures using the GL_COMPRESSED_RGB_PVRTC_4BPPV1_IMG and GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IMG formats working using glCompressedTexImage2D, but when I try to subload using glCompressedTexSubImage2D I get an GL invalid enum error. The PVRGL_IMG_texture_compression_pvrtc extension says that these formats should work w/ glCompressedTexSubImage2D. Is this a known bug or is there something I’m missing here?
I’m using version 2.07.27.0484 of the PC emulator SDK.
This indeed looks like a bug. However please note that there are additional constraints defined in the extension:
if one of the following conditions occurs:
* <width> is not equal to TEXTURE_WIDTH.
* <height> is not equal to TEXTURE_HEIGHT.
* <xoffset> or <yoffset> is not zero.
This means you must replace the entire texture level, it is not possible to just modify a subrectangle.
Good to know. I didn’t realize this limitation existed, however, at the moment I’m getting an INVALID_ENUM error, which has to be related to the format. Is there any chance that this bug will be resolved soon? The component I’m working on requires subloading of compressed textures to operate efficiently, so I’m kind of stuck w/o it. Is there a way for me to know when this issue has been fixed?
Also, can you confirm whether the requirement to “replace the entire texture level” is a limitation of all PowerVR SDKs, or just the PC emulator? For example, does PowerVR texture compression for the Mac or Android have the same limitation?
If this is a limitation of the PowerVR texture compression format, it is a fairly significant one for me and probably means that I will not be able to use the format. A rather critical piece of my application requires incremental subloading of compressed textures. The alternative to use non-compressed textures or to subload an entire level at a time are both likely to have a rather large impact on performance.
Are there other platform-dependent alternatives that don’t have this limitation?
This requirement is present in all implementations of the extension (as per the spec).
The way that PVRTC works makes replacing sections of a texture non-trivial (at least without introducing artefacts).
Looking at the ETC spec, it seems to have the same limitation, so I don’t think there is another obvious solution that will be available on your target platforms.
See:
http://www.khronos.org/registry/
Thanks for the quick response.
Can I get any estimate as to when the bug that is preventing me from calling glCompressedTexSubImage2D w/ the PVRTC tokens at all, as mentioned earlier in this thread, will be resolved?
I’ve filed this issue in our system as BRN32028 and the engineer responsible for it will look at it shortly. I we can reproduce it then he should fix it for a future release. The next release will be in February.
Can you confirm whether the bug BRN32028 has been resolved? I’m using version 2.10 of the SDK.
Hi Deep,
It seems a number of bugs were not passed on when the previous engineer left - so I’m afraid that the bug has not yet been fixed. I have investigated this issue and am going to make sure it gets done for the next release (hopefully we’ll be able to get this out mid-cycle via the auto-updater). Really sorry that we’ve dropped the ball on this one, I’m going back through all bugs now to make sure that this doesn’t happen again.
For reference, this bug was actually a duplicate of another bug filed just previously, BRN31992, so look out for this BRN when we next update the SDK.
Regards,
Tobias