0

I am currently grappling with the computation of mipmaps for block compressed formats (BC7) in Vulkan. The limitation with these formats is that the size of the block compressed texture needs to be a multiple of 4. While I can comfortably make this adjustment for the level 0 of the mipmap chain, subsequent levels, which are half the size of the preceding level, present a challenge. For instance, if the size of level i is a multiple of 4, level i + 1 doesn't necessarily have to be. Could it be feasible to sidestep the traditional rules of image mip level sizing and establish custom sizes for each level?

Here's an illustrative example:

Level 0: 1080x1080 (remains 1080x1080)

Level 1: 540x540 (remains 540x540)

Level 2: 270x270 (becomes 272x272)

Level 3: 135x135 (becomes 136x136)

...

Level n: 4x4

I've also explored the possibility of converting Non-Power-Of-Two (NPOT) images to Power-Of-Two images. This adjustment could resolve the problem as the entire mipmap chain would then possess sizes that are multiples of 4 (with the exception of 2x2, 1x1, etc.). However, this approach seems suboptimal, particularly when a 1027x1027 texture would have to be adjusted to 2048x2048.

Given these considerations, what possible solutions could be implemented to tackle this problem?

wilson
  • 1
  • 1
  • "*I am currently grappling with the computation of mipmaps for block compressed formats (BC7) in Vulkan.*" This should be done by an off-line tool, not by you. – Nicol Bolas Aug 02 '23 at 13:26
  • I may have mischaracterized the issue initially. For texture compression, I'm actually using the ISPC Texture Compressor. – wilson Aug 03 '23 at 17:39

1 Answers1

0

The limitation with these formats is that the size of the block compressed texture needs to be a multiple of 4.

No such limitation exists in Vulkan. If you use a block-based image format, and the size is not a multiple of the block size, that is fine. Vulkan will ensure that pixels from blocks that are only partially within the image size will not be accessed (by most image accessing processes, at least).

However, this does mean that, for a given image subresource, there is a distinction between the actual size and the size of the data (based on the block count). Again, this is fine in Vulkan, and the API makes it clear when which one matters.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • Thank you for your insight. You are right, my primary issue was with transferring data from the buffer to the image. I was operating under the impression that the image extension must be aligned to a multiple of 4 due to this problem. – wilson Aug 03 '23 at 17:41