BC7 Mipmap Problems in Catalina and Mojave

I've run into two (possibly related) problems involving mipmaps in BC7 RGBA Unorm textures.

The first, and more serious, is a crash when uploading the last mipmap level of a texture. Thus far this has only happened on two machines, both running Catalina. Also, only certain textures cause the crash, but there doesn't seem to be anything unusual about them. From the crash reports:

MacOS 10.15.7 19H1519, Intel Graphics 4000 (this is from a debug, single-threaded build)

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.driver.AppleIntelHD4000GraphicsMTLDriver	0x00007fff25cff33d CpuSwizzleBlt + 11667
1   com.apple.driver.AppleIntelHD4000GraphicsMTLDriver	0x00007fff25ce7ca0 -[MTLIGAccelTexture replaceRegion:mipmapLevel:slice:withBytes:bytesPerRow:bytesPerImage:] + 1387
2   com.apple.driver.AppleIntelHD4000GraphicsMTLDriver	0x00007fff25ce7e2f -[MTLIGAccelTexture replaceRegion:mipmapLevel:withBytes:bytesPerRow:] + 74

MacOS 10.15.7 19H1419, Intel Graphics 5000 (this is from a release, multi-threaded build)

Thread 9 Crashed:
0  com.apple.driver.AppleIntelHD5000GraphicsMTLDriver         0x00007fff2973b9c0 CpuSwizzleBlt + 9224
1  com.apple.driver.AppleIntelHD5000GraphicsMTLDriver         0x00007fff2972714b -[MTLIGAccelTexture replaceRegion:mipmapLevel:slice:withBytes:bytesPerRow:bytesPerImage:] + 1385
2  com.apple.driver.AppleIntelHD5000GraphicsMTLDriver         0x00007fff297272c3 -[MTLIGAccelTexture replaceRegion:mipmapLevel:withBytes:bytesPerRow:] + 64

I'll post the full crash reports to Feedback Assistant.

The second problem only happens on Mojave, and results in what looks like garbled pixel data in the mipmaps (I don't have access to the machine to do a frame capture). I can work around this issue by disabling mipmaps in the texture sampler.

There are no Metal validation errors, and neither problem happens on Big Sur (I don't yet have a Monterey machine). Uncompressed textures are fine, as well, although mipmaps for those are generated on-the-fly rather than uploaded.

Padding the source pixel data doesn't help, so the seg fault likely isn't caused by a too-large or unaligned read.

Has anyone else run into problems with mipmaps in BC7 compressed textures?

Up vote post of dwn Down vote post of dwn
1.8k views
Posted by
dwn
Reply
Add a Comment

Replies

Hi dwn,

Thank you for filing a Feedback Assistant ticket with us! If you can post the ticket number here, I can route it to the driver team to investigate.

In the meantime, my recommendation is to verify sure that you are satisfying alignment and size requirements for the lowest mip level.

This is particularly important for compressed textures, where you still need to provide a full block at the lowest mip level, as well as maintain the alignment. For the specific case of BC7, you need to make sure the alignment is 16 bytes and that you provide Metal a whole block of size 16 bytes.

Posted by
Graphics and Games Engineer
Up vote reply of Graphics and Games Engineer Down vote reply of Graphics and Games Engineer

  • The ticket link is: https://feedbackassistant.apple.com/feedback/9753271

    I've verified that our BC7 textures are properly aligned--each mipmap's with and height are proper multiples of blocks (indeed, DirectX and Vulkan also freak out if they aren't). Since each block is 16 bytes this would enforce 16-byte size alignment as well. The pixel data for each level begins on a 16-byte boundary as well.

    Since our BC7 textures are generated offline I'm not sure what's actually stored in the padded space--the crash is in a swizzle so it's remotely possible there's a stray bit pattern that's causing problems.

    Most of our textures upload just fine, but I've isolated one that causes the crash and I'm going to try writing a stripped-down application that loads that one texture. The file uses the KTX format so I can also try loading it with MetalKit's texture loader to see if there's a difference there.

    —
    dwn
Add a Comment

I've now confirmed that the crash also happens using the texture loader from MetalKit. I've added a simple test application to the feedback ticket.

Posted by
dwn
Up vote reply of dwn Down vote reply of dwn
Add a Comment

This crash is still occurring in MacOS Monterey (12.1, 12.2 and 12.3.1). We've confirmed it with end users with Intel HD Graphics 4000, Intel HD Graphics 5000, and Intel Iris Pro. One such device is a Macbook Pro 15" from 2015.

I've updated the Feedback Assistant ticket as well.

Posted by
dwn
Up vote reply of dwn Down vote reply of dwn
Add a Comment

I use BC7 textures fine on Intel and M1 systems. But these are 2018 MBP with AMD and Intel parts.

One problem with KTX files is that each mip level has a 4 byte length. This messes up the upload of data, and Metal typically wants 16B alignment of each mip level. Metal validation should flag that.

If you are doing a memcpy then that may not be the issue. I was originally trying to mmap uncompressed ktx files when I hit this issue.

Posted by
Alecazam
Up vote reply of Alecazam Down vote reply of Alecazam
Add a Comment

Our mip levels are 16-byte aligned--each level is copied out of the KTX container before we use it. This crash seems to be specific to certain GPU and/or OS versions. We don't have this problem on any M1 system, or on most Intel systems.

The feedback assistant ticket has a very simple MetalKit project that shows off the error.

Posted by
dwn
Up vote reply of dwn Down vote reply of dwn
Add a Comment