Skip to content
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

Compressed textures sampling #2148

Open
AlexanderDevaikinEnscape opened this issue Jan 31, 2024 · 2 comments
Open

Compressed textures sampling #2148

AlexanderDevaikinEnscape opened this issue Jan 31, 2024 · 2 comments

Comments

@AlexanderDevaikinEnscape
Copy link

AlexanderDevaikinEnscape commented Jan 31, 2024

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.

@billhollings
Copy link
Contributor

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

@AlexanderDevaikinEnscape
Copy link
Author

AlexanderDevaikinEnscape commented Feb 1, 2024

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants