-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
The KDFS says:
...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. |
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. |
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). |
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! |
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)
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".
The text was updated successfully, but these errors were encountered: