Open mcourteaux opened 4 months ago
This is the patch that I described in above:
diff --git a/examples/08-update/update.cpp b/examples/08-update/update.cpp
index 109efb0ff..200c92e20 100644
--- a/examples/08-update/update.cpp
+++ b/examples/08-update/update.cpp
@@ -173,18 +173,11 @@ bgfx::TextureHandle loadTextureWithUpdate(const char* _filePath, uint64_t _flags
, NULL
);
- const bimg::ImageBlockInfo& blockInfo = getBlockInfo(imageContainer->m_format);
- const uint32_t blockWidth = blockInfo.blockWidth;
- const uint32_t blockHeight = blockInfo.blockHeight;
-
uint32_t width = imageContainer->m_width;
uint32_t height = imageContainer->m_height;
for (uint8_t lod = 0, num = imageContainer->m_numMips; lod < num; ++lod)
{
- width = bx::max(blockWidth, width);
- height = bx::max(blockHeight, height);
-
bimg::ImageMip mip;
if (bimg::imageGetRawData(*imageContainer, 0, lod, imageContainer->m_data, imageContainer->m_size, mip))
Patch is nonsensical for block compressed textures. Requirements is full mip chain but since 1x1 can't exist with block compression, it's to keep 4x4 (or minimum block size) until you reach 1x1.
Also you should test changes like this with D3D, and other renders.
Describe the bug For example BC2 has a texel block size of 4x4, however it seems that BGFX and BIMG are trying to produce mipmaps for this format all the way until 1x1. This gets detected by the Vulkan validation layer as an error.
To Reproduce Steps to reproduce the behavior:
make clean && make -j8 config=debug64 example-08-update
renderer_vk.cpp:695
.You should see excerpts like this:
For BC2:
Scroll a lot to the right, and you'll see the complaint regarding the extent of the image. So bimg does produce mipmaps that respect this minimum block size, but Vulkan is not having it, as the mipmap itself is determined to be smaller than that.
Same goes for BC3:
BC1:
Expected behavior
To quote Nicol Bolas from here:
So, if I understand correctly, you should be able to generate the mipmaps all the way down, but we just need to adjust the size of the
Region
indicated by theVkCopyBufferToImage
struct? We'd have to actually lie refer to the target of the image as if it's cropped to the sub-texel-block-size region.After some investigation, it seems that the example itself is doing this (pay attention to the first two lines, with
bx::max()
):https://github.com/bkaradzic/bgfx/blob/9547e798675330df5dacbed8a72feec012ff3ed5/examples/08-update/update.cpp#L183-L205
Deleting those fixes the issue for me on Vulkan. OpenGL is not complaining much in either case. Can't test D3D.