# compressed texture subloading **URL:** \ **Category:** PowerVR Insider\ **Created:** [December 3, 2010, 6:24pm UTC](https://forums.imgtec.com/t/compressed-texture-subloading/939 "2010-12-03T18:24:59Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![deep](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@deep](https://forums.imgtec.com/u/deep)\ **Post date:** [December 3, 2010, 6:24pm UTC](https://forums.imgtec.com/t/compressed-texture-subloading/939/1 "2010-12-03T18:24:59Z")
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. ---
**Author:** ![xmas](https://avatars.discourse-cdn.com/v4/letter/x/958977/32.png) [@xmas](https://forums.imgtec.com/u/xmas)\ **Post date:** [December 6, 2010, 9:52am UTC](https://forums.imgtec.com/t/compressed-texture-subloading/939/2 "2010-12-06T09:52:17Z")
This indeed looks like a bug. However please note that there are additional constraints defined in the extension: Quote: CompressedTexSubImage2D result in an INVALID\_OPERATION error only     if one of the following conditions occurs:         \* \ is not equal to TEXTURE\_WIDTH.         \* \ is not equal to TEXTURE\_HEIGHT.         \* \ or \ is not zero. This means you must replace the entire texture level, it is not possible to just modify a subrectangle. ---
**Author:** ![deep](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@deep](https://forums.imgtec.com/u/deep)\ **Post date:** [December 6, 2010, 1:27pm UTC](https://forums.imgtec.com/t/compressed-texture-subloading/939/3 "2010-12-06T13:27:17Z")
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? ---
**Author:** ![deep](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@deep](https://forums.imgtec.com/u/deep)\ **Post date:** [December 7, 2010, 12:50pm UTC](https://forums.imgtec.com/t/compressed-texture-subloading/939/4 "2010-12-07T12:50:59Z")
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? ---
**Author:** ![GordonMaclachlan](https://avatars.discourse-cdn.com/v4/letter/g/c68b51/32.png) [@GordonMaclachlan](https://forums.imgtec.com/u/GordonMaclachlan)\ **Post date:** [December 7, 2010, 2:05pm UTC](https://forums.imgtec.com/t/compressed-texture-subloading/939/5 "2010-12-07T14:05:23Z")
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/](http://www.khronos.org/registry/) ---
**Author:** ![deep](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@deep](https://forums.imgtec.com/u/deep)\ **Post date:** [December 7, 2010, 2:50pm UTC](https://forums.imgtec.com/t/compressed-texture-subloading/939/6 "2010-12-07T14:50:12Z")
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? ---
**Author:** ![GordonMaclachlan](https://avatars.discourse-cdn.com/v4/letter/g/c68b51/32.png) [@GordonMaclachlan](https://forums.imgtec.com/u/GordonMaclachlan)\ **Post date:** [December 10, 2010, 4:31pm UTC](https://forums.imgtec.com/t/compressed-texture-subloading/939/7 "2010-12-10T16:31:05Z")
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. ---
**Author:** ![deep](https://avatars.discourse-cdn.com/v4/letter/d/ce7236/32.png) [@deep](https://forums.imgtec.com/u/deep)\ **Post date:** [September 17, 2012, 7:26pm UTC](https://forums.imgtec.com/t/compressed-texture-subloading/939/8 "2012-09-17T19:26:03Z")
Can you confirm whether the bug BRN32028 has been resolved?  I’m using version 2.10 of the SDK. ---
**Author:** ![tobias](https://avatars.discourse-cdn.com/v4/letter/t/c67d28/32.png) [@tobias](https://forums.imgtec.com/u/tobias)\ **Post date:** [October 10, 2012, 9:01am UTC](https://forums.imgtec.com/t/compressed-texture-subloading/939/9 "2012-10-10T09:01:59Z")
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