DataFormat icon indicating copy to clipboard operation
DataFormat copied to clipboard

PVRTC minimum data work count

Open mlvdm opened this issue 5 years ago • 4 comments

As detailed here: https://github.com/KhronosGroup/KTX-Specification/issues/131 It appears that a PVRTC surface must always have at least 2x2=4 data words. Specifically this seems from this: https://github.com/KhronosGroup/KTX-Specification/issues/131#issuecomment-664576977

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

mlvdm avatar Jul 27 '20 22:07 mlvdm

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 avatar Jul 28 '20 09:07 fluppeteer

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.

fluppeteer avatar Jul 28 '20 09:07 fluppeteer

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

mlvdm avatar Jul 28 '20 16:07 mlvdm

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!

fluppeteer avatar Jul 28 '20 21:07 fluppeteer