Bug Blocky Pixelated Shader Texture Sampling on M1 Apple Silicon

I sent in my Intel macbook pro for service so I switched back to my M1 Max laptop.
Unfortunately I noticed a new bug.
(Case 1397304)

The texture sampling in my simple shader shows up extremely pixelated and blocky, as if the bilinear filtering is not working properly. My shader works properly under Intel version of the editor, and Windows.

This texture has no compression on it. The filtering is set to 16x anisotropic.

It looks like a mipmap issue as the problem is different at different angles. That's my guess.


Same scene, same texture, same shader, same compression settings (none, crunch=off)
2021.2.8 on both.

Works on Windows and Intel Mac.
I tried every permutation of settings on the texture and it doesn't fix the issue.

Here are some images to show the issue. I've set the texture sample scale to .01 to show the artifacts more clearly.

https://i.imgur.com/ewEQJEW.png

 

Here is a simple repro with the shader and texture.

Check SampleScene.unity on Apple Silicon and it will be blocky. Check it on any other platform and it will be fine.

 

Anybody else running into this or able to reproduce the bug? I submitted this minimal repro and still no response from QA.

 

Just had a friend hit a similar issue in WebGL. Could be a driver bug in M1. He "fixed" it by disabling mipmaps.

 

Response from Unity QA on my issue:

:/

 

I ended up here after researching very similar symptoms. Crucially, just like sameng's minimal reproduction scenario, we were relying on a stochastic sampling logic generated with Amplify Shader Editor. However, on Unity 2020.3.18f1 the half/float precision does not seem to be related. In fact, in the minimal example above the word "half" isn't even mentioned and we see the issue all the same.

We went digging a little deeper: Amplify's procedural sampling node does nothing particularly outlandish. Eventually we started suspecting it was down to the ddx/ddy command, which can have different implementations depending on rendering API used. You can read about it in this very in-depth blog.

However... we eventually tried to cut the reliance on ddx/ddy all together and are still seeing the same issue. To be continued...

 

Yeah, it's not a half-issue. There's something else going on. Thanks for chiming in.