Weird scenes inside VkSubresourceLayout

I am seeing weird results in VkSubresourceLayout in 2 cases. In both cases the implementation (Ubuntu 18.04 with Intel open-source driver) reports that the features I want to use are supported in linear tiling.

In the first case, which is with VK_FORMAT_R8G8B8_UNORM, the values in the VkSubresourceLayout returned by vkGetImageSubresourceLayout are the same regardless of the mipLevel value passed in the VkImageSubresource. offset is always 0 and the size and pitches are always the same.

In the second case, with VK_FORMAT_BC2_UNORM_BLOCK, and the image having multiple layers, the returned VkSubresourceLayout for mipLevel = 0 shows values for an uncompressed texture with a 4-byte texel. The texture is 256x256. rowPitch is reported as 1024, and depthPitch & arrayPitch as 262144 (1024 * 256). size though is reported correctly as 458752 which is the same as the the input data. There are 7 layers in this data and obviously 7 * 262144 > 458752. If I ignore the pitch values and just copy the data into the mapped image, everything works.

I don’t know if these things are implementation bugs or me misunderstanding the spec. If the former, i’d like to report them.

Please don’t waste your time telling me to use optimal tiling. I am working on a general texture loader that supports both.

Okay. Maybe I understand the second case. Is rowPitch the number of bytes until the next row of blocks not texels? BC2 has 4 x 4 blocks so 64 to a row and the blocks are 128 bit or 16 bytes. 64 * 16 = 1024. This doesn’t explain the arrayPitch value though. Shouldn’t that be 1024 * 64 (rows of blocks) = 65536?

Seems a known (fixed) bug: anv: Properly handle GetImageSubresourceLayout on complex images · Mesa3D/mesa@b99493c · GitHub
You need to wait for package release, or try running unstable (e.g. prebuilt from padoka PPA).