MoltenVK icon indicating copy to clipboard operation
MoltenVK copied to clipboard

Compressed textures sampling

Open AlexanderDevaikinEnscape opened this issue 1 year ago • 2 comments

Hello. I have asked in discord without much luck, so let's try to talk here :)

I wonder if somebody have ever had issues with compressed textures. With BC3 compression for instance. In some cases (mostly weird NPOT texture sizes) sampling some of the mip levels gives zeros at some texture locations. On the screenshot it's LOD 4 where artefacts appear - note that not complete mip level looks broken, rather small square-like regions. Sometimes only one mip level is affected, sometimes multiple - it clearly depends on the texture size. And it never happens with POT texture sizes. The problematic texture in this case has 135x1500px, with 4th LOD having 8x93px. Though texture must not be that extremely thin to have issues - I've seen it with a big variety of NPOT sizes like 1503x1216, etc.

Fun enough, Xcode capture shows texture contents completely correct - see screenshot. Blue shade is where LOD4 is sampled. Screenshot 2024-01-31 at 09 52 45 Screenshot 2024-01-31 at 10 03 26 We do upload mip data padded enough to match compression format block size. So it seems to be caused by sampling process. It works fine on Windows and AFAIK it worked fine with AMD GPUs on mac and even with M-macs running our application via rosetta, but when we started building native arm binaries this issue appeared.

I tried changing sampler parameters, disabling anisotropy, etc. - no luck. Another screenshot is our debugging view of the texture mip level 4 sampled directly via nearest sampling filter. It should have been continuous green texture data, but it has black parts: Screenshot 2024-01-31 at 09 33 18

I've tried to reproduce it with pure Metal using our compression code such that data matches, and could not - both texture contents and sampling work fine in my repro project. There are some differences between our app code and my repro case, such as argument buffer usage.

My current workaround is to scale textures to pot resolutions, but this is suboptimal.

Do you have a sample app, or other mechanism for us to replicate the issue here?

billhollings avatar Jan 31 '24 23:01 billhollings

I can share binary release build. Stripped down as much as I could to only have the most related passes and data.

There is a start.sh script to launch the app with all the needed env variables set. Texture compression is on by default. You can edit systemPre.cfg file to disable compression - simply uncomment corresponding line.

Thank you!