Mip-Map with Block Compressed Texture

Hi,

Now I’m trying to use block compressed texture in my renderer.

I met an issue when I try to use 320x320 BC1 image (generated using texconv.exe in DirectXTex).
It has 9-level mip map and the filesize is 68468 bytes because of

  • DDS header (+ DX10 extra header): 148 [bytes]
  • MIP0: 320x320 [px] => 80x80 [blocks] x 8 [bytes/block] = 51200 [bytes]
  • MIP1: 160x160 [px] => 40x40 [blocks] x 8 [bytes/block] = 12800 [bytes]
  • MIP4: 20x20 [px] => 5x5 [blocks] x 8 [bytes/block] = 200 [bytes]
  • MIP5: 10x10 [px] => 3x3 [blocks] x 8 [bytes/block] = 72 [bytes]
  • MIP8: 1x1 [px] => 1x1 [blocks] x 8 [bytes/block] = 8 [bytes]

I need to copy the data part of the file into an OptiX buffer using buffer->map(mipLevel, …) but I found an inconsistency between the file and OptiX buffer.
I mapped all the mip levels of the buffer at once and took address differences of each mip level to the its previous level.
The address differences are:
51200, 12800, …, 200, 32, 8, …

In my understanding the number of blocks is round up so that they can contain all the pixels of a mip level.
For MIP5, 10x10 [px], the number of blocks should be 3x3 because one block size is 4x4.

Why does the MIP5 of OptiX has only 2x2 [blocks] = 32 [bytes] in this case?

Thanks,

Would you be able to provide the block compressed texture you’ve been using for analysis?

I uploaded the dds texture with the original png image:
https://drive.google.com/open?id=1fz-pLN3CRl2EXzKcmNlC8kXqo5Mhiqmp

I generated the dds file from the png using texconv.exe with the following options:
texconv.exe -nologo -dx10 -f BC1_UNORM_SRGB -srgb -y grid_80p_white_18p_gray.png

I checked the dds file by texdiag.exe (in DirectXTex repository) and it says:
The number of blocks for every mip level is
6400, 1600, 400, 100, 25, 9, 4, 1, 1

Thanks.

Any updates?

Not really. There might be a padding error in the block compressed buffer management.

The bugreport is only 7 days old. Depending on which module needs to be fixed (e.g. driver, compiler, SDK) it can take months between a new bug report and a fix available in the resp. module for end-customers.

Thanks for your reply.

It’s enough at the moment to be able to know that the issue is a bug or I misunderstand the structure of block compressed texture.