Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PVRTC minimum data work count #12

Open
mlvdm opened this issue Jul 27, 2020 · 4 comments
Open

PVRTC minimum data work count #12

mlvdm opened this issue Jul 27, 2020 · 4 comments
Assignees

Comments

@mlvdm
Copy link

mlvdm commented Jul 27, 2020

As detailed here: KhronosGroup/KTX-Specification#131
It appears that a PVRTC surface must always have at least 2x2=4 data words.
Specifically this seems from this: KhronosGroup/KTX-Specification#131 (comment)

From the OpenGL ES IMG_texture_compression_pvrtc extension:

  • For PVRTC 4BPP formats the imageSize is calculated as:
    (max(width, 8) * max(height, 8) * 4 + 7) / 8
  • For PVRTC 2BPP formats the imageSize is calculated as:
    (max(width, 16) * max(height, 8) * 2 + 7) / 8

Seems like 32 bytes is the minimum PVR image size possible.

This is kind-of ambiguous with this document's phrasing of "At least one word of PVRTC data must exist in each mip level of a texture.", because although it's correct it probably should read "At least four words of PVRTC data must exist in each mip level of a texture because interpolation requires 2x2 data words".

@fluppeteer
Copy link
Collaborator

The KDFS says:

At least one word of PVRTC data must exist in each mip level of a texture.

...which does imply a single block. Logically it should be possible to wrap, so that the "adjacent blocks" wrap to themselves. However, it may be the case that older hardware doesn't handle this properly, and therefore the minimum effective size is 2x2 blocks; I think this was discussed at the time this got documented, but I wouldn't like to say anything authoritative. I'll investigate and report back.

@fluppeteer
Copy link
Collaborator

Follow-up: Some very early hardware was indeed limited to at least 2x2 physical blocks (the logical image size could always go down to 1x1). Newer hardware has lifted that restriction. I'm seeking clarification on whether/how to document this.

@mlvdm
Copy link
Author

mlvdm commented Jul 28, 2020

I agree it's possible for decoding to work with a single block just wrapping to itself in every direction (I mentioned that in the original thread too), but it's not clear to me if/when that became supported in HW (and in GLES/VK? I found no extension for it...)

Although for 1x1 logical it's moot, for 2x2 logical it seems like having 2x2 data words would actually allow you to store 4 "exact" values and use each of them once with 100% weight, it seems possibly compressors relied on that (or not, I don't actually know). If 2x2 logical would use a single word I think the possible interpolations would be pretty tricky.

However, it's important to know whether or not to expect the single word or the 2x2 words in a mip if you are, say, reading a KTX2 texture which has this DFD embedded in it (which is the context in which I encountered this). I would be totally happy with saying "it's always 1 word" or "it's always 2x2 word for compatibility" or "it's always 2x2 word for the logical 2x2 mip case" or "there's this bit in the DFD that discriminates the cases" or "it's 2x2 for PVRTC v1 and 1 word for PVRTC v2" (or even "KTX container should encode this information", although I imagine the KTX spec people may be less happy with that).

@fluppeteer
Copy link
Collaborator

Thanks, mlvdm.

It sounds as though very old (PCX rather than SGX) hardware had the 2x2 block limit. The 1x1 support would have worked on the same hardware that introduced PVRTC2, but would still have applied to the 1x1 case.

You're quite right that an encoder could store 2x2 blocks and use that to reconstruct only texels that fall within a smaller-than-4x4 area. I'll look into it and provide an MR to document it (whether it's a note or normative), in any case.

Good catch - thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants