compressed texture subloading

This topic contains 8 replies, has 4 voices, and was last updated by  Tobias Hector 5 years, 2 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #30386

    Deep
    Member

    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.

    #34605

    Xmas
    Member

    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:

            * <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.

    #34606

    Deep
    Member

    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?

    #34607

    Deep
    Member

    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?

    #34608

    Gordon
    Moderator

    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/

    #34609

    Deep
    Member

    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?

    #34610

    Gordon
    Moderator

    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.

    #34611

    Deep
    Member

    Can you confirm whether the bug BRN32028 has been resolved?  I’m using version 2.10 of the SDK.

    #34612

    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

Viewing 9 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic.