-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Example 08-update: Non 1x1 texel block size ImageFormats get copied incorrectly from buffer to image in Vulkan. #3311
Comments
mcourteaux
changed the title
Some TextureFormats with non-1x1 block sizes generate too many mipmaps.
Vulkan: Non 1x1 texel block size ImageFormats get copied incorrectly from buffer to image.
Jun 14, 2024
mcourteaux
changed the title
Vulkan: Non 1x1 texel block size ImageFormats get copied incorrectly from buffer to image.
Example 08-update: Non 1x1 texel block size ImageFormats get copied incorrectly from buffer to image in Vulkan.
Jun 14, 2024
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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()
):bgfx/examples/08-update/update.cpp
Lines 183 to 205 in 9547e79
Deleting those fixes the issue for me on Vulkan. OpenGL is not complaining much in either case. Can't test D3D.
The text was updated successfully, but these errors were encountered: